Not the person that said, but let me try. First, Nix isn't for configuration management, it can do bunch of other things, but even when it comes to configuration management it is still superior to the popular tools:
Ansible/Chef/Puppet/Saltstack
They try to be declarative (following less popular CFEngine) but they are still iterative. Saltstack is closest as originally the order of operation was based on the declared dependencies.
They still ultimately come down to just perform iterative steps, with the difference that operations are idempotent.
The biggest drawback they do have is coming from the fact that they have system with a state and they modify the system state to get selected files/services/packages/etc in new state.
Nix lives up to its name, and when configuration happens it starts from nothing and then builds everything based on the configuration.
The result of it is, let say you use the traditional CM tool to install a package. Then later on you decide the package is no longer needed so you remove "pkg.installed" declaration. What actually happens though is that the existing systems will continue to have the package installed (until you add "pkg.removed"). What's even worse is that any new instance you spin up will not have the package installed, so everything will be drifting. This is the primary reason why there was the immutable system movement. That's all to avoid those scenarios.
In contrast, in Nix, if you remove package from list of installed packages, or you remove file that you declared by nix config, they will be gone from the system. The configuration is basically describing your system.
Now, as mentioned above, that's just one piece of things Nix can do. I primarily use it for reproducible builds I really like that if a package won't build on your computer it probably will fail to build on mine as well (it's something that docker promised, but IMO failed to deliver), but let's stick to configuration management.
Another big thing is that all changes are atomic, you either get your change or the change did not apply due to error, you will not get in a in-between state, like frequently happens with CM.
Another thing is (and what I wrote above is prerequisite for this to work correctly) is that you can do rollbacks. And it works with things that are considered hard. For example NixOS by default use X11, but you can enable Wayland with some configuration changes. Then you can just revert the config back and get back to your old X11 installation.
This also makes system upgrades less dreadful.
Let's say you have your setup, but you need to use different version of openssl or maybe compile it with different flags. In traditional OS you probably would not do that or if there was a vulnerability you would wait for help from vendor as there might need to be multiple packages updated. But if it is something smaller, maybe you need python package, you would build your own version, you would place it in artifactory, then have ansible task to upgrade it on your instances.
With nix you will use overrides[1]. Nix then will see it, and if the compiled version is not in its cache it will pull all dependencies and recompile it automatically then place it in its cache.
If you set up a binary cache yourself (you can either use SaaS solution, or even just set up an S3 bucket) you can have your machines automatically pull the compiled version from it. Nix doesn't care about versions of packages either (the versions are only for the user) instead it uses cryptographic hash generated from things like source code, package dependencies, architecture, compile options, etc) this means if you cache compiled version and modify package to add some other options, it won't accidentally use the other package it will either pull the right one or recompile the code.
[1] https://nixos.org/manual/nixpkgs/stable/#chap-overrides