I begrudging tried tailwind css recently. I was shocked to find that when using a CSS framework where you embed all of our styling in HTML, I STILL needed a css build process to do trivial things like customize the default link color.
If you're a solo dev, sure, you're free to do anything you want and nobody will balk or complain about you causing them extra work or having to clean up a mess later. If you're on a small project and the CSS will fit onto a couple sheets of A4 paper, you also won't have enough volume of code to see major benefit because you could just rewrite an entire UI of that scope from scratch in a few hours. But on a team working with a larger codebase Tailwind solves real problems in maintaining styles across developers and over longer periods of time.
Merits of semantic classes and class hierarchies are very debatable. And CSS dropped the ball with style composition (which e.g. SCSS fixes). And media/container query ergonomics aren't ideal. But essentially hardcoding styles inline is a very weird reaction to these. A bit like "let's get rid of variables and hardcode values in functions because OOP inheritance caused a mess".
I’ll take its idiosyncrasies which take less than an hour or so to understand (spread across a few days of usage) as opposed to raw CSS which is a totally different sort of madness.
I can see that Tailwind does prevent architecture astronauts going crazy. But that's a cultural issue, not technological.
It’s a fundamentally different way of working. It enables styling by a different set of principles than pure css.
Merely looking vaguely like inline styles does not make it so.