I’m familiar with Chef, Salt, and Ansible, but I believe the following will apply to Puppet as well: the configuration management tools that I’m familiar with work by essentially merging many complex state changes. These state changes typically come from multiple providers, who are not necessarily aware of each other’s work.
Differences in configuration management software come down primarily to how users define those changes, merge behavior, and how the changes are applied. Furthermore, the prior state of systems (on which changes are applied) can be quite difficult to predict, and the configuration software is expected to just work regardless.
I compare configuration management to implementing a multi-master database, hard to reason about, easy to screw up.
Containers (as already mentioned in the comments) are the preferable alternative whenever they are an applicable replacement. In the case of Docker, each container definition starts with a known input, applies changes sequentially and produces an output. These definitions can be chained together. I compare their usage to function composition, easy to reason about, hard to screw up.
The fact that you’re talking about configuration management at all implies you’re managing long-running servers and not using a PaaS solution. IMO this is a big maintenance headache, and is to be avoided when possible.
All this is to say: there are some times you’ll need to run servers yourself, there are certain tasks that will require configuration management, but they should be used as little as possible; favor containers and PaaS whenever you can. There are differences between configuration management solutions, but those differences are dwarfed by the advantages of just not using them at all.