I’m very fond of Guix for a few reasons:

• functional package management. Every package in the Guix store is in its own isolated directory (identified by the hash of that package + its dependencies) and every package knows where its dependencies are in the store, so you can have packages that depend on conflicting versions of libraries, for example.
• transactional system upgrades, and ability to roll-back to a previous version of the system if an upgrade goes wrong somehow
• per-user package management (each user has their own set of packages that doesn’t require root to manage)
• packages/repositories (“channels”) are declared in a programming language (Scheme; not my choice of language but a language nonetheless) and version-controlled as git repos
• packages are built from source by default but can also be available as pre-built binaries (“substitutes” in Guix lingo) if a trusted CI server has them available. I think this is the “best of both worlds” of a binary and source based package manager (this does come with an annoying pain-point, where you don’t really know if you’re going to get pre-built substitutes when you run guix upgrade, especially as packages that are less trivial to build also end up more likely to not be available from the CI server)
• being able to install a package from a different source (e.g. a tarball, git branch/commit) (guix install --with-source, --with-branch, -with-commit, etc)
• the default repository adheres to GNU’s free distro guidelines, which is always (for me) a plus. That being said, there’s maybe a dozen user-created channels with non-free kernels and non-free apps if that’s your thing too.

Package Management section of Guix manual

Now, one thing I don’t like about Guix is that its unconventional approach to package management often makes building more complicated packages a challenge, because those packages have to be patched to behave properly in the Guix environment.