Throw rocks at me if you like, but ansible is a more swiss army knife than just CM; I can trivially provision a cloud something (and there are a lot of cloud somethings that it supports, not just "hurr, I can make an ec2 instance hurr"), then do traditional config-management upon those resources, then do local tasks -- which I recognize may rub folks the wrong way, but for good or bad it's damn handy in a lot of my specific use cases -- then go back to doing cloud or CM stuff, all within the same playbook
Also, it really jams me up their crazy nomenclature <https://docs.saltproject.io/en/3005/glossary.html> trying to be "cutesy" with really going all-in on that salt thing. I have heard similar, justified, complaints about Brew's "Cellar", "Keg", "Tap", etc
A co-worker keeps mentioning we should use terraform, but I'm not getting a very good answer, and haven't had time to do my own research, on why we should use TF rather than writing playbooks to provision AWS resources. Your comment above makes me wonder if, because I'm so steeped in Ansible, I'm not realizing that some of the other CMs are lacking these functions and need to lean on TF, where in Ansible you do not. I'm willing to admit that TF might be a better way of expressing it.
As far as cutesy language, I don't really get jammed up by it, but I'll admit I kind of roll my eyes whenever I come across it. If it's a great tool, I'll overlook that (as in the case of brew). Kind of a "bless your heart" situation. :-)
At the time I selected Ansible, Saltstack had just had a fairly serious "we invented our own crypto" issue, but also Ansible's agentless approach was nice for my environment, though saltstack did have some great demos of what you could do with their approach, and, I had friends who were working on Ansible, which seemed like it was worth something... I'll take a look to see if Saltstack is in the same space as uPlaybook.
