Well it's a bit confusing. On Guix' wiki General features you can read:

Guix keeps track of these references automatically so that installed packages can be garbage collected when no other package depends on them - at the cost of greater storage requirements, all upgrades in Guix are guaranteed to be both atomic and can be rolled back.

The roll-back feature of Guix is inherited from the design of Nix and is rarely found in other operating systems, since it requires an unorthodox approach to how the system should function (see MicroOS).

And then on its wiki Guix System (operating system) Roll-back you can read:

This is accomplished by a combination of Guix's functional package manager, which treats each package and system configuration as an immutable and reproducible entity,[58] and the generation system which maintains a history of system configurations as "generations."

So the system configurations on a Guix system are actually immutable, as opposed to regular gnu+linux distributions, which can change the system configuration on the fly. What else is immutable on Guix, I can't tell, but at least you can not change its system configs. What is atomic is the upgrades.

I'm not sure, but as Guix borrowed these properties from Nix, I'd think this applies to Nix as well.

In other words, at least the Guix system has immutable components. And further, the system config which is immutable, is also declarative. Combining those two things might be intimidating, since it's not like on the fly one can go and change the system config, which might be required when debugging some misbehavior, and it's what most distros document, then one needs to learn about guile, and a bit about functional programming I guess or at least their basics... Deploying systems might take advantage of such declarative configurations though...