Heh, my thinking basically. As Guix is a GNU project, it adheres to FSF definitions of freedom. That means there will be no proprietary drivers or similar in the official repositories.
This is true. We offer deblobbed Linux (linux-libre) by default.
However, it is very simple to customise packages, including the kernel package, e.g. to apply patches, use different sources, or to exercise your right to disagree with the Linux libre upstream on what blobs should be deleted from the kernel.
That said, I consider freedom by default a feature and it works very well on most of the hardware I use (an exception is an on-board Radeon graphics chip in a desktop machine I don't use much).
Creating package variants is almost trivial; it's certainly no harder than, say, customising Emacs. Guix blurs the lines between user and maintainer, so using custom package definitions is a supported use-case. At work even our scientist users create custom packages in case they are not available in Guix upstream yet.
Sounds very similar to my experience with Gobolinux. If the source is packaged sanely (proper support for --prefix or equivalent) a user can roll up a recipe ready for Compile with a single command and a url to the source needed.
