quoting Rhetorica:

No one ever asks for sound change appliers—but that is because no one knows how to use them or what features they offer, and they are generally not willing to admit it.

Anyone who has much end-user experience with SCAs can tell you that the process of debugging your SC list so the program finally comprehends exactly what you want it to do, a painful and tedious process not given full justice by your phrasing "knows how to use them", is often more work than just sound-changing all your words by hand. If you're only applying six or eight changes to a wordlist that's thousands of entries long, it would be worth it. But using an SCA to apply longer and quite complicated changes of the sort you actually find in natlang histories makes one want to rip off one's own arms and gnaw them to bits, because relatively few real-world changes are so simple as x > y / _z. Just as often it's something like "change the rightmost t to a k if and only if the word does not already contain a k" where the SCA needs to examine the contents of the entire word in order to correctly make the requested change (and none that I know of will actually do this; they all seem to be limited to mere pattern matching). Or, you'll get things like "ijj, ij, j > ij, j, 0 / respectively" or some other such situation where multiple lines are necessary but no matter which order you put them in they interfere with each other's outputs. That's just two examples off the top of my head. But there's a whole sea of possible sound changes that SCAs are too dumb to deal with nicely, and in principle they're all fixable by re-working the structure of your SC list. But figuring out how to do so - especially if there's several of these messes and they interact with each other - is no easy task for people who aren't programmers.