Tailwind is actually a lot like inline styles in certain ways. Whether that's a good thing or not depends on your use case. If you are using a component based framework it ends up, IMO, being way better and less complicated to use the abstraction you already have, your components, as your styling abstraction rather than trying to layer a second abstraction (the cascade approach) on top of it.

The biggest advantage over inline styles is that you are constrained. The idea is that you set up the primitives for your application's styling system: which colors are in use, which font weights, all the way to things like which border radii are valid. Your devs can then only use those.

You are correct that theoretically you can modify them to do anything, but in practice I find that people are extremely unlikely to violate the scheme (in ways like you described, adding a border to bg-red).

As for abbreviations? I think that's probably just eye of the beholder. Since you tend to add a lot of these to your HTML it helps it not get too ridiculously out of hand.

I spent years working with more traditional CSS schemes (including my all time least favorite, BEM), and it was pretty consistently a nightmare within the context of component driven applications. For a while now I've worked with tailwind and it feels like a massive step in the right direction.

I think it's one of those things that really doesn't make sense until you try it and feel the difference for yourself.

Tailwind has a lot of advantages if you read the documentation rather than conjecture about what you think it might do.

>...which is a fair advantage as most frontend developers I talk to don't even realise that specificity is a thing.

Really? I'm not sure I could take someone seriously if they called themselves a frontend developer and did not understand CSS specificity.