Yes, it's true you can achieve an equivalent output on multiple hosts either through container based (or some other form of virtualization), or through a PFCT like
cfengine. As the perl motto goes, TMTOWTDI. However, one could posit that being ~absolute (given some base assumption of host kernel features), storable and self-contained, a virtualized image (container-based or otherwise) is far more 'complete' a unit to the unskilled random (ie. most users) than a series of steps (OS setup, some change, some other change) performed with a PFCT. That's pretty subjective, though.
Uh-oh, here comes trouble! A developer comes over and wants 10 of the 1000 nodes to work a little differently.
In a formalistic and most desirable case, the prescribed node changes should be specified, versioned, documented and pushed. By the developer. With no input from systems administrators or operations people. The best way to do this is usually to define it holistically. Your approach emphasizes the speed of cowboy modification of running machines, whereas a formalistic (and continuous deployment ready) approach emphasizes the security, identifiability and repeatability of instituting the same environment through a standardized process. Both have their benefits, but if the latter is automated it shouldn't be any slower and would still offer benefits over the primarily manually driven PFCT-based ad-hoc change style approach you seem to be championing. Hate to put my finger on it, but an example would be that your salary and/or availability is no longer required.
All of a sudden we have unexpected behavior due to the new instructions in the config file. One hundredth of our hosts are doing something different and we have to now account for that in anything else that happens in the future.
That's just the point. By having a known entity that is versioned and self contained you don't have these issues. By making manual, ad-hoc changes with a post-facto configuration tinkerer (PFCT) like cfengine, you are out on a limb.
The practical differences between these two is that the Cfengine change can be tested and applied quicker than a Docker
Containers are very fast. I don't think you can make this argument without citation to numbers, nor do I think it's often relevant as speed of deployment, within certain boundaries, is rarely a bottleneck.
it doesn't force you to choose how to update your application ("am I updating the image? am I adding an image? am I changing the Dockerfile? am I changing the config? should I restart the docker or the service? do I have to reconfigure the autodetecting whatsit?" etc)
A formalistic release process that incorporate unit testing and the provision of test infrastructure, particularly that for systems including multiple, versioned services that must operate in tandem, requires some overhead. This overhead is about enforcing segregation between developer output and (automated) operations concerns to support continuous integration and continuous deployment.
I'd suggest that right now we're going to see this same sort of issue turn up regardless of how we choose to manage services (except manually, in an ad-hoc, error-prone, oldschool, cowboy style fashion), and in future we're going to see less and less systems administrators performing manual processes because some automated segregation mechanism or other will become popular enough to reduce operational demand in many companies for that skillset.
Quite separately to the above, I agree that docker fails to provide much of a meaningful feature set in this area, and that docker files might not be ideal. However, something will come along and fill in the gaps, eventually. Probably incorporating corosync/pacemaker or other, proven, prescriptive, cluster engines with self-healing / high availability features that rely upon continuous deployment of well segmented and versioned service instances for their very feasibility.