I don't understand frameworks like this. You are basically tying presentation with markup. God forbid you want to create more than one theme for the same HTML!
It is very liberating to use Tailwind instead of creating unique CSS classes for every div in a page. The code is much more maintainable - in a single stroke Tailwind gets rid of selector specificity issues, design inconsistency, and naming woes.
From a programming perspective, the conventional style of "semantic" CSS classes creates deep and fragile coupling between markup and CSS. It goes against everything good code is supposed to be - when you change the structure of the HTML you're forced to change the CSS, and if you truly use the power of CSS selectors, then modifying CSS becomes a difficult enterprise: one change can create multiple unrelated changes at a distance.
Tailwind solves all this, with just two downsides: until you spend a few hours mucking with it, the markup look will look unwieldy, and you have to be ready to really think about semantic CSS and "separation of concerns" dogma we've taken for granted for so long.
Hence "separation of concerns" - to the extent that it's a good idea in the first place - doesn't work for html+css, and similar concerns mean it doesn't work very well for html+scripts.
Put another way, leaky abstractions are worse than no abstractions. Better to keep things transparent and merely expose helpers, instead of pretending you can hide complexity when you cannot really hide it.
So, if I'm making a theme, and I want a different color for the text, I have to replace "text-gray-900" with my hex code for purple?
Also, what if my theme is about making the design more compact, or increasing density? How do I customize thousands of elements with different combinations of class="ml-6 pt-1"?
Oh, and don't get me started on "bg-white rounded-lg". God forbid your theme wants squared boxes on black background.
If you want to change density of the design, you can change the spacings centrally in the configuration itself. But if you need a non-proportional change, then it isn't any different than BEM+SASS environment where you'd have to go into every CSS class and make the change. I think it is even better than BEM here because you only need to change classnames in HTML, which is co-located with the style, and it doesn't cause cascading changes due to specificity etc.
To me the opinions you hold seem to come from not having tried it in good faith, which was how I used to judge functional CSS as well. If the current CSS style you use serves you well, that's fine you don't have to explore. But if you've wondered whether there is something wrong with the way we do CSS today, then Tailwind could be an eye-opener.
Who does this? It sounds like an exercise in pain and futility.
It's less theming in the sense of css zen garden and more encoding variations of style in css instead of relying on more class names.
The TLDR is that you don't lose anything by starting out this way, because at any point you can extract (think @apply) higher level utilities or semantic classes, but gain that you can get a good looking design in place quickly by having useful constraints, not needing to switch context all the time, and not being forced to make up names for everything. While few sites need to conform to the "Zen Garden principle", Tailwind won't stop them from doing so, if you put in the work that it makes optional.
I'd agree this seemingly takes the idea of semantic styling to an extreme (although I haven't gone too deep into the framework).
It's a design system with constraints, which automatically gives me fewer and better options.
Using something like Bootstrap is probably easier and quicker if you're unfamiliar with writing CSS though.
All in all, quite far from styling with inline `style` (but it takes a bit of learning on the thought process behind it).