I really can't think of many things I like about SatlStack. It is such a poor execution of a Puppet/Chef replacement. While some people tout speed and scalability, I haven't seen much of those gains. I am using an older version of Salt, but that largely is its own fault. If I could upgrade, which I can't due to incompatibilities between salt versions.
I can name several things.
* The biggest one is that I often have to redeploy changes 2 or more times. this mostly has to do with Salt's brain-dead implementation of git.
* It's error messages and output is often cryptic and meaningless. Debugging Salt scripts are difficult, and often require me to use shell commands or scripts to print out custom debug information
* Its targeting semantics are difficult to get right.
* Module output description names (especially when trying to find problems) often to match anything like the repository layout or file names.
* Salt 2015 to later versions is not a simple upgrade. Salt completely changed the syntax of their file structure and their modules. So any large project is likely to be stuck running old buggy versions since the change effort to upgrade is not trivial.
* Output from a run on the Salt master is different than if ran on the individual servers using salt-call. This causes us to do the one thing that this tool is supposed to solve, which is having to run changes on each server independently.
* failed changes on one server can leave your infrastructure in a mixed and inconsistent state.
There are more points, but these are the top ones.
Saltstack was chosen and implemented by a predecessor, and it has been the single thing that has wasted the largest amount of time in my limited work schedule. We manage mobile gaming services for multiple clients. Most of these clients create billions of requests per second to our infrastructure.