Easier just to quote the reason he gives:

“With inline styles, there are no constraints on what values you choose... Utilities force you to choose...

You can't just pick any value want; you have to choose from a curated list. Instead of 380 text colors, you end up with 10 or 12.”

And of course, those colors are fully customizable.

in what way is that consistent tho?

In what way is it not? You'll consistently get 10 or 12 colors instead of getting an inconsistent set of colors, for example.

But I only want the element to be the color it IS, not a range of colors it could be. Whats to stop a dev using $concrete when they should be using $cloud? or $linkGray instead of $headerLinkGray?

these inconsistencies compound, especially across teams.

Nothing would stop them from choosing to use cloud vs. link gray but it's far easier to identify and fix those cases than it is to have #CCC, lighten(#CCC, 10%), etc. around the codebase. This doesn't fix human error, just reduces it.

I admit, after the middle of that article anything would look good.

It's a good realisation that there is no real separation of semantics and styling between HTML and CSS. XSL would have been one solution, but it was just too XML-ly. Personally I found it a joy; I could design my pages with pure semantics alongside a turing-complete stylesheet.

However now we have web components - your HTML and CSS are tightly coupled, but scoped. And the semantic / styling separation is provided by the shadow DOM. So no need to create inner platforms like Tailwind.