It depends on your priorities. If you care about package availability and the broader ecosystem, Nix would be a better choice[1]. Nix has a larger community size, lower barrier for participation, and is more forgiving regarding non-free software. Its package count likely exceeds the AUR too, if you exclude duplicates.
Guix, on the other hand, is better suited for the more adventurous folks. It's built on Scheme, which many find appealing.
Both Nix and Guix can be installed on other Linux distros. Both are now available in the official Debian repository. Additionally, Nix supports macOS quite well. It even supports FreeBSD and Cygwin too, although it's probably not as mature.
Guix combines the specification language, API, and base distribution into a single monorepo. This makes it a bit like the linux kernel in terms of scope and ability to adapt and update itself without external dependencies. My understanding was that this wasn't quite the same for Nix, and that's led to some trickiness in the way that the project evolves. What do you think?
As a user who occasionally makes my own packages for software deployment, I can learn very quickly how to write a package description by grepping through the guix main repo and looking at how other packages are written. That's probably similar for Nix, but it's something that I found refreshingly clean and flat in guix and I'm frankly hooked.
Guix and guile are in separate repositories just like nixpkgs and nix.. It wouldn't be nice to mix these. The difference is really about the amount of coevolving the language can make to the specific tasks.
Guix, on the other hand, is better suited for the more adventurous folks. It's built on Scheme, which many find appealing.
Both Nix and Guix can be installed on other Linux distros. Both are now available in the official Debian repository. Additionally, Nix supports macOS quite well. It even supports FreeBSD and Cygwin too, although it's probably not as mature.
[1]: https://repology.org/repositories/graphs