You're ignoring the crux if the issue. This isn't about running proprietary microcode or not.
All x86 Guix users are running proprietary microcode. Period. This is a fact, whether they know about it or not. It's not optional. Would it be great if they didn't have to? Sure. But that's not the world we live in.
This is about withholding information about an update to the proprietary microcode they are already running. There is absolutely no reason not to offer users this choice, given they're stuck running the ROM blob to begin with. The only reason the FSF and Linux-libre do this is because they want users to feel better by not knowing about the blob they're already running. There is no freedom gained, only the illusion of freedom. Users don't know what their ROM microcode does just as much as they don't know what the update does. The only thing we know is it fixes a bug.
I believe a world where all software, firmware, and hardware is free would be ideal. I also know that is not the world we live in, and so I believe in empowering users with the information about what options they have, what the security/freedom/privacy/etc tradeoffs are, and letting them make their own choices. The FSF's push for restricting information so people believe they are not running any nonfree code is diametrically opposed to my views for this reason. I believe having the illusion of freedom is harmful to the cause for software freedom, as it obfuscates the reality of the current state of affairs. Every single die-hard FSF fanboy needs to learn about the 27 blobs running in little ROMs inside their computer, so they stop believing they live in a fake freedom utopia and come to terms with the reality we live in. Maybe then we'll have even more people pushing for firmware freedom.
I'm not even saying Guix should ship the update. But actively censoring information about the existence of the update? That's just ridiculous. Your users are already running the blob. Stop trying to pretend they aren't and tell them it's broken already. How is it better when users are stuck running broken proprietary software when a fix is available because you refuse to inform them about it? That's completely irrational.
Incidentally, this is a falsehood:
> closed-source, unauditable binary blobs, which constitute a fundamentally greater security risk than any auditable code repository ever could
This kind of absolutist view is another problem with this school of thought. Blobs can be in a position where, by the nature of their access or lack thereof to the rest of the system, they pose minimal security risk even if presumed completely evil. This is evidently a much lower risk than, say, low quality open source code in a position of extreme privilege with a large attack surface. Auditability doesn't mean things get audited or all bugs fixed. I have no problem trusting that a blob in a harmless I/O microcontroller poses little to no security risk to me over, say, certain open source cryptography/key storage implementations I've seen which raise a million red flags. Context matters, and the FSF's refusal to consider any context or nuance is also hurting users by not empowering them to make the decisions that are the best for them.