Trying to figure out why people think it's a good idea. It's certainly not the vision of web dev I was trained on.
When I started writing CSS I would commonly encounter modestly sized websites of only a couple hundred pages with 17 thousand lines of CSS or more because of frameworks like Bootstrap. At least a few hundred of those lines would be overrides and just as many would probably be redundant.
My team launched a 6 thousand page website this past year with only a couple hundred lines of vanilla CSS and roughly 3 thousand lines of Tailwind generated CSS total.
At the end of the day, Tailwind is a zero-runtime, tree-shakable CSS framework generator. The burden of naming many common and universal design artifacts is alleviated. Class reusability goes through the roof. Custom stylesheets regain the ability to be edited with confidence again. It’s good. It makes the HTML a bit bloated and ugly which deters people at first, but dev tools pick up the slack and so far I’ve yet to see any performance impact there.
That's just how tailwind works.
There are exceptions. We could use postCSS to code-split critical paths for CSS. It sounds like a fun side project for some framework's ecosystem. Unfortunately, the current state of CSS is very much good enough for me for now. I'm much more concerned about main thread work from JavaScript and optimizing images for the web, for example.
1. It gives you bunch of sane defaults around colours and spacing. If you consistently use Tailwinds classes then you'll get a nice grid and (usually) complimentary colours.
2. You're using a a framework or view library that supports reusable components. For React, this is obvious. For Phoenix, you use LiveView components or the Phoenix "static" components.
Tailwind only really works when you apply its classes to components, then reuse the components (or more tersely: "Reusable styles via reusable components")
Thinking out loud, now: the problem of CSS and HTML depending on each other makes me think of the dependency inversion principle. Basically, make both of them depend on some common interface or protocol, so they can change independently. Utility classes are in the same territory, but I don't think it's reasonable to demand that the shared language be app-independent, or put another way, to demand that a library author relieve you of the burden of naming your domain objects.
I suspect the ideal approach is app-specific "content-agnostic" classes, defined in terms of some library of helpful classes that are not themselves directly invoked in HTML, with #ids as needed for specialization. But I don't know, maybe I'll just try to the tailwind thing out on a new project.