My impression of other tools, like Chef, is that they try to abstract away configuration and setup where ansible just feels what I would try to build if I had a bunch of ssh shell scripts. You’re always pretty close to the actual commands being run.
Saltstack offers some very cool orchestration features, and being built on ZMQ offers some interesting capabilities.
Also, with it not requiring an agent, it's feasible for you to use it as an admin even if the rest of the team doesn't adopt it. Other tools that run on agents generally require some amount of higher level buy-in on using the tool.
For me ansible is perfect, I have some private services on a variety of VPS (read: mail & co for me and family, because the Internet is not yet another cloud...) and at work I use it for syncing my config and installing software on our lab-cluster as well as in my ${HOME} on the local HPC-center. Saltstack/Puppet/Chef won't help me with any of these, as I'd need multiple server for control alone.
Logic in yaml sucks though – I'd probably jump ship anytime anybody provided the same thing (e.g. plain configuration management for "classical", non-cloud setups) with a real DSL (be it Python-based or whatever).
An even simpler tool is Python Fabric, which is closer to something like Expect (but in Python and over SSH).
It's far far far better than anything else... (specially Chef... It's light years ahead of Chef!)
For the starter... It only needs one single component to work , my computer!
Puppet/Salt you need a master server (with HA, load balancing, etc...) and a client running on every machine.
This by it self already add an order of magnitude more complexity than using Ansible.
And for Chef... Oh boy... you need a master server, a client running on every node plus a client running on your computer! (really... for me this by itself is already more than enough reason for me to plain refuse working with Chef).
Now... putting this details aside, the way that I use Ansible allows me to use the dynamic inventory feature (so... I don't store actual infra state on the automation) and to create playbooks that act as DevOps helpers if you may...
So... let's say that I need to setup a MongoDB Replicaset... I just call the `playbooks/provision-mongodb-replicaset.yml` playbook with the needed parameters and... the playbook takes care of everything. From the EC2 provisioning till the Hard disks partitioning (up to the RAID setup) going over OS settings, security roles, apps installations, etc..., till it goes, install MongoDB and create the replicaset for me.
All this with a single command from my computer without the need of anything else! =P
(and I have this `provisions-` and `update-` playbooks for everything that we run on my current job + for the things that I set up when freelancing... Including AWS only stuff like VPCs, or OpenVPN + VPC + Peering + etc...)
This is my primary problem with ansible. I find that it's been really great for managing things from my local machine, but that model breaks down a little once you have a medium / largish fleet of machines in some cloud provider's space. On top of that, if you have strict security boundaries between different environments/resources, then running ansible scripts that touch a ton of machines becomes more of an exercise in key management than anything else. I know that there are tools out there like AWX and rundeck, which wrap a lot of ansible functionality, but I've found the push model to be a little hard to manage at scale.
We're using ansible almost exclusively for config mgmt tasks, and I'd like to find a way to make it work better for us, but the agent model used by puppet/chef/salt sounds really appealing, especially when I want to role a change out to a large set of machines