Both nixOS and Guix are different to 'regular' distros in the way that they are declarative: there is a file that describes the full OS: every user, every package, every system service, where the bootloader goes and so on. The main idea is that you can take that file, nuke your hard disk, reuse it and you'll have the same OS byte by byte. This concept of reproducibility is not only very comfortable, but has profound ramifications in security (you know no compiler or library has been tampered with malware) or science.
But it goes deeper: Since the OS is described by a single file you can roll back to a previous version if your file is hosted on git (both OS manage this transparently without the need of a VCS). Users can have their own 'local copy' of that file with their own programs, including their own libraries with different versions. You can have different files as 'profiles' (one for work, one for personal projects, one for gaming) you can activate at any time when you want to switch tasks, or you can try your friend configuration on a chroot or isolated environment on top of your own system.
The main difference between nixOS and Guix is that guix uses guile scheme as configuration language for that particular file. I have plenty of '(packages (if is-laptop acpi)...)' entry on my own files.
guix shell is just a way to create a temporary environment to try something quick without polluting my OS. For instance, if I want to do some hacking on python2 I would do 'guix shell python2' and it will open a shell for me with python2 without changing my python3 binary and python3 libraries on my main system.
BTW you don't even have to change your whole system, both nix and guix can be installed on top of 'regular' distros (google 'guix foreign distro', which is the way I manage my rasperry pis).
There is way more than all that, I definitely encourage everyone to give it a try, it's a mind bending new way to use a OS.
If you want to "profoundly" improve security, you verify the whole install against a cryptographic hash on every boot, and you refuse to boot if the verification fails, and you keep the hashes in tamper-proof hardware -- like Android and ChromeOS do, but no other Linux distro does except for a distro specialized for cloud servers called Bottlerocket that is poor in resources (e.g., attention from developers).
NixOS's security is pretty poor even compared to the low standard of popular Linux distros because although it does incorporate one very good idea (and it is not reproducibility -- its refraining from giving packages as much ambient authority most OSes give them), security is mostly about paying attention to dozens of boring details, which the NixOS project does not care about as much as for example Fedora does. E.g., here is the project not caring about supply chain integrity: https://news.ycombinator.com/item?id=36268776.
Another example: if you install Google Chrome onto Fedora the standard way (namely, dnf install google-chrome-stable) it points your Fedora install to an RPM repo hosted by Google, so that from then on, even if everyone in charge of the Fedora servers lost their minds, your Fedora install would continue to keep your browser up-to-date in a very timely manner (because it has been configured to look directly to Google's servers for updates, and Google's Chrome team is well-paid and has a stellar reputation for security and in particular for timely delivery of security updates). In contrast, when I installed NixOS's Chrome package, it arranged things so that every time I updated my NixOS install (using nixos-rebuild IIRC) it would look to NixOS's servers, so the security of my browser (and the browser is the source of many, many security vulnerabilities) depends on a NixOS maintainer getting the update from Google, then providing it to me. But you see, the Fedora way of handling that package has a single point of failure (namely, Google) whereas the way NixOS chose has two points (namely, Google and a NixOS maintainer who is probably a volunteer and might quit or die at any time -- and the NixOS project has not system in place to respond to that event in a timely manner if my experience with the NixOS project is any indication).
NixOS's machinery for updating packages is very flexible, so I'm sure it would've been pretty easy to arrange for NixOS's Chrome package to work the way Fedora's does, but the relevant decision maker at NixOS simply didn't think of it. But security consists in large part in paying attention to details like that. ADDED. Actually, now that I think of it, the Chrome project's servers provide only RPMs and DEBs, so for NixOS's maintainer of the Chrome package to handle updates to Chrome the way Fedora does would require that the installation of the Chrome package causes (as part of dependency satisfaction) the installation of RPM or dpkg and maybe parts of dnf or apt (so that later on, the nixos-rebuild command can look for updates on Google's servers), so it is not as easy as I was envisioning when I wrote that "it would've been pretty easy". (Still, that is probably how I would do if I were the NixOS maintainer.)
(quick edit) Guix packages are basically .scm (scheme) files on git, so the fedora/nix example does not apply either. Every file can be opened and inspected, most of them are basically a git clone + checking a hash. You can decide to use substitutes (binaries) or no, and substitutes are usually similar byte by byte across systems. As an example, this is the guix config for installing CRIU: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages...
Given said that, I am ready to spend some of my funemployment time installing and using nix as my daily driver for a few months, so I will have more info and first hand knowledge of all that.
