Because the styles are being specified at the element level and thus there is no need for “class name glue” to track which elements should have which styles, globally, across your entire application and org.
You can then compose at the component level instead for re-use. Components are a better unit of composition because they include the markup, styles, and even business logic and state in some frameworks. It’s better to have everything in one place.
This is a valid criticism but “works out of the box” was the important part there.
The style attribute, not the style element.
Oklch is unambiguously good. I meant that it’s a stretch to say it fulfills the requirements of a design system that works out of the box (because it doesn’t fulfill that at all, actually). But it’s still good!
Tailwind’s colors are indeed an inferior approach, but that’s because they pre-date oklch! That is actually the point I was making, too 
p-1 is equivalent to padding: 0.25rem;. It’s a scale. It’s configurable. I haven’t used Tailwind in a long time but it looks like at some point they rebuilt the whole thing on top of CSS variables or something, so idk how it works anymore.
The lack of a unit is historical. Tailwind is an extension of a “utility class” technique in which you create a standard set of classes (padding, font size, etc) and use those. Pre-generating classes for every imaginable unit would be far too many, so they chose a reasonable scale and stuck with that.
Of course nowadays there is no stripping from a set list (tree-shaking as you described); instead the compiler generates classes on the fly. You can, in fact, write p-[4px] if you want to.
I am not defending this approach, and I have been very clear that I think Tailwind’s time has come and gone. But it’s far more interesting to investigate why things are the way they are instead of just assuming everyone else is stupid and lazy.
