The inflexible soup can come just as easily in the opposite direction though. Eventually you have prominent-action-7 and you need documentation to understand what all these supposedly semantic names actually mean in reality and figure out which one you want. Or you want to change the look of your prominent actions, so you change the class definition and then later you realize someone made a totally different kind of thing look like a prominent action and just reused the class but now it should no longer be the same. Making a change in one place breaks other things in totally unrelated places in the app. So in order to avoid that, you need to look closely at every use of a thing anyway when making a change to make sure you're not breaking something. And if you're doing that, then you're not even getting any benefit from your abstraction anymore, you almost might as well change every instance of the thing one by one if you have to carefully comb through them all anyway.
> So if I want to change the colour of all prominent-actions across my web app
As I was just saying, it's naive to think this would ever be a simple one-line change of a constant. It will inevitably be a moderate sized undertaking no matter what you do, because of all the cruft and coupling that may have built up under the old assumptions. But it's also not something you're doing every day, so it should be far from the first thing on your mind when thinking about which patterns are most helpful to use.
But, even putting all that aside, using utility classes like Tailwind doesn't even prevent you from abstracting as much as you'd like. You just do it at a different level. You're not likely writing static html on every page anyway, you're probably using code to generate your html whether that's React components, server-side rendered views with partials and templates, templates in a static site generator, etc. So you can still do the abstraction you want at the level of your components or your view code instead of via css classes. In that world you can think of tailwind as just a higher-level version of the underlying css properties. And you're still free to repeat yourself or DRY-ify your code as much as you want (though as I allude to above, I tend to think DRY in programming is often very overrated).