I have worked with nightmarishly complicated Ansible playbooks and roles designed to provide declarative infrastructure when it didn't exist in a module. If all you had to change was a group_vars setting, you could be confident in your change. But if you had to edit a role, playbook or task, nobody was sure if it would break something in the future or not. It was much less robust than a real module because it was just the DSL.
With a Python DSL you could write code that was declarative, but because the language is complex, lexing is more difficult, and simple changes to configuration become more error-prone.
By moving to images and containers, the majority of configuration management is now largely unnecessary. We will always need a CM tool, but they should give users less rope to hang themselves with, not more.
So as immutable systems grow - that's a damn good thing. I personally think the docker ecosystem is a trainwreck currently, but that's only my opinion, and doesn't really affect anyone else. But the same concepts have been around for ages in EC2 in immutable systems.
What typically happens is people use the CM tool to provide a higher level abstraction than Bash for describing the image build, so they get features that should have always been in docker files but never were (templates are the biggest one for me).
Further, there is always a need to deploy the "undercloud". Even in heavily containerized microservices setups, there's a need to handle all the magic upgrade fun of upgrading a Mongo cluster, a Cassandra cluster, or a Kafka setup.
Whether we call it configuration management, app deployment, or just a structured way to push scripts around and see what failed, we're going to need those tools.
I believe immutable systems is a fantastic philosophy where it works. It doesn't work everywhere. And CM tools still have a niche for those that want to use them in the build process.
If folks want straight docker files instead, I'm also cool with that.