The linked article is about package management, not configuration management. Whoever set the title of this post didn't understand the point of the article. From the comments, people seem to confuse and conflate configuration management, job automation and package management. To run a successful infrastructure at any scale you need all three.
If it's about package management, why did it even talk about Chef, Ansible, etc? It seems to me that the package management changes he describes can be exposed at a top-level layer of "tell me which packages and versions you want", which has NOTHING to do with the configuration managers he mentions.
Literally every single one of the tools he said we can do better than, could use his package manager with almost no changes.
Imagine a world in which the treatment for heart attacks was to get the victim to sit down and press icepacks to their chest. Someone writes an article about "Why icepacks aren't good enough" as treatments for cardiac arrest. It would be clear why the article started by talking about icepacks.
Not really. He's complaining about Ansible/Chef/etc when they have nothing to do with the real issue, which is package management. The rest is just tangential.
As best I understand: he explains why you see certain problems when using the Ansible/Chef etc. (the icepack) and then explains why these are symptoms of underlying problems with package management (the heart-attack) which can't be resolved through the use of an icepack.
I disagree, the tools (or, well, Ansible, which is the only one I'm familiar with) are declarative, as he describes. He says "these tools are not enough", then goes on to say that you need stateless package management, through a non-sequitur.
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.