I have pretty extensive experience using Salt very deeply, and while it's good, I recommend it only with some pretty severe reservations.
First is that management of the master is still a big, big pain point. Unless something's changed in the last few months, you can't meaningfully cluster a salt master. Minion keys must be accepted on each master in turn. Auto-accepting minion keys is risky as hell, too. Master signing keys sound like a great idea until you realize that it means you can't bootstrap a minion sui generis.
My other big problem with salt is that Salt formulas are really popular, but are _completely_ uncomposeable. Time and time again I found places where the action of a formula needed to depend on data that existed elsewhere in the pillar, but pillars can't be parameterized with pillar data (obviously). They're also not versioned at all, so occasionally breaking changes are merged in (I myself am personally guilty of doing this). The idea is a decent one ("separate the data from the code!"), but they end up being a real headache in a complex environment.
There are a few other, more minor, issues I had with Salt, but really my main beef is that Salt is an extraordinarily effective footgun. If you try to avoid writing "salt scripts" (think: Ansible playbooks), it's very, very easy to end up with a really messy dependency tree, crazy templates, etc. Yes, I know that discipline matters, but people aren't perfect.
I agree with most of your points, but having used other systems, I just have to point out that all configuration management systems are footguns that give you armor over 50% of your foot, and let you aim how you please.
I think salt helps to enforce that you can't arbitrarily compose disparate datasources with overlapping namespaces and have it magic it's way to a sane solution.
Chef tries to compose its data via a very sensible yet hard to get right ordering mechanism. Salt says "nope, you overlap, it breaks, and you get to fix it". I prefer salt's approach but what I like more is the temptation to write an external pillar provider that will do the right thing for me when I get to that point. It's imperfect but quite powerful.
First is that management of the master is still a big, big pain point. Unless something's changed in the last few months, you can't meaningfully cluster a salt master. Minion keys must be accepted on each master in turn. Auto-accepting minion keys is risky as hell, too. Master signing keys sound like a great idea until you realize that it means you can't bootstrap a minion sui generis.
My other big problem with salt is that Salt formulas are really popular, but are _completely_ uncomposeable. Time and time again I found places where the action of a formula needed to depend on data that existed elsewhere in the pillar, but pillars can't be parameterized with pillar data (obviously). They're also not versioned at all, so occasionally breaking changes are merged in (I myself am personally guilty of doing this). The idea is a decent one ("separate the data from the code!"), but they end up being a real headache in a complex environment.
There are a few other, more minor, issues I had with Salt, but really my main beef is that Salt is an extraordinarily effective footgun. If you try to avoid writing "salt scripts" (think: Ansible playbooks), it's very, very easy to end up with a really messy dependency tree, crazy templates, etc. Yes, I know that discipline matters, but people aren't perfect.