Literally every single one of the tools he said we can do better than, could use his package manager with almost no changes.
You can specify the packages you want in Ansible, and it will abstract away everything else, giving you what you asked for. Ansible's config language wouldn't look any different if it were using nix (and it probably can), so what he says doesn't follow:
Ansible (et al) aren't enough => We improve a part of the underlying system => Ansible looks exactly the same, but is magically now enough.
Ansible (et al) aren't enough => We improve a part of the underlying system => We build a new tool that makes use of the improvements and is therefor better than Ansible.
There is a fundamental difference between Ansible and co. and NixOS. These tools take you from an unknown state, look at the part of this state you configured in the Ansible files, and apply the modifications necessary. NixOS will take its cue from a single file (possibly with includes) describing the entire machine.
Concretely, if you tell Ansible "package X should be present", apply the configuration and then remove this line before reapplying the configuration, package X will still be present, even though it's not listed in the configuration. I don't mean that as a criticism of Ansible, for my purpose it's about as good as it gets, but it's two different paradigms.
Individual users may benefit from versioning their config files, but usually not their programs. Big business might do both, or just as likely screw it up and version code but not configs (I'm looking at you, crontab).
In practice, everybody screws something up, whether individually or part of a small/big business. The tools are typically not the problem; the humans and how they use them, are.
If you follow it, you'll get a package like "mycorp-nginx", which is an atomic piece of configuration management that not only controls nginx's configuration wherever you deploy it, but also nginx's version on those same machines.
Basically, with this strategy, instead of installing nginx, you only install mycorp-nginx; the config-package then installs the thing it's configuring as a dependency. That dependency is locked to a specific version, so it'll only upgrade when you push out a config-package that changes that dependency.
I think the more useful way to think of packages and configuration are that they are necessary compliments. An unconfigured package doesn't do what you want, and configuration without a package doesn't do anything at all.
The theory is, they're both components of system state, so why not manage them together?
But to me it sounds like saying that text and layout are necessary compliments for a magazine, so why not manage them together? Because it turns out that is a horrible idea. Anyone who does professional publishing manages them separately.
"Do it all" tools rarely do it all well.
I think there are a few more steps in there. Assuming identical OS and arch, you've probably got:
* software packages that should be identical on all nodes in the cluster
* a set of software packages that should be installed on all nodes
* configuration that should be identical (e.g. 99% of an nginx config)
* configuration that is unique to the host (e.g. a hostname)
Or perhaps:
* packages limited to a single OS (traditional software packages for Linux)
* packages limited to a single organization (identical portions of configs)
* packages limited to a single node (hostname)
Anyway, I'm playing around with using Nix for all but the unique-per-host stuff. I see potential, but it may or may not pan out. I seem to always need a custom version of nginx, or ruby, and I find making custom Debian packages rather cumbersome, even with a fair amount of experience.
The whole point is that those aren't different things. Once you create a proper package management system, it is also a proper configuration management system. The article didn't do a great job of explaining it, but fire up a few VMs and give NixOps a try.