全体のドキュメント構造を表すHTMLと全体のスタイルを表すCSSを別々に管理する古典的手法が誤った関心の分離であることには同意しますが、だからといってTailwind CSSがやっているようなものは好きになれません。

（ここでは簡単のため仮想DOMの是非については述べず、HTMLとJSXなどを区別しません。それは本題ではないため……。）

まず、私はコンポーネント指向での設計はよいものだと思っています。Webページをコンポーネントの集まりとして捉え、各コンポーネントがそれぞれでHTMLとCSS（そしてJavaScript）を持つというのは、より本質的でよい関心の分離であると考えます。

開発者と利用者が実際に関心を持っているのは常にコンポーネントであり、その実装言語などではないはずです。（例えばスタイルのおかしな部分があったとして、それは「この部分のスタイルがおかしい」であって「スタイルのうちのこれがこの部分でおかしい」ではないはずです。）

この考えは同時に、HTMLが全体のドキュメント構造を表したり、CSSが全体のスタイルを表したりするものが好きになれないということにも繋がります。（HugoなどのHTMLテンプレートエンジンがこれに含まれます。）

しかしこれは、HTMLにインラインでCSSを書いてスタイルを定義したり、HTMLのクラス名としてCSSを書いたりすることを好ましく思うことと同義ではありません。Tailwind CSSは好きではありません。なぜなら不要だと思うから。

前述した古典的手法、つまり「それがHTMLであるかCSSであるか」によってのみ分離することは誤った関心の分離だと思いますが、だからといってコンポーネント内でその両者が同じ文脈で書ける必要はないと思っています。コンポーネント内であればHTMLとCSSは分かれていてよいでしょう。Vue SFCやSvelteがやっているようなもの、もしくはCSS Modulesでよいでしょう。これに尽きる。

よくTailwind CSSのメリットとして、スタイルに一貫性を持たせられることが挙げられているように思います。しかし一貫性を持たせる方法なんてものは他にもいくらでもあって、その中にはCSS変数もあります。CSSが標準としてサポートしている方法です。

また、記述量が減ることもメリットらしいですが、モダンな開発環境であればエディタの言語サポート機能によって記述量なんてどうとでもなります。むしろ大量のクラスが横並びになる状況と従来のCSSではどちらのほうが読み書きしやすいでしょうか。

メディアクエリが書き易いという意見もあります。（そしてこれをインラインCSSとの差別化ポイントであるとして、Tailwind CSSを擁護するものがあります。）しかしこれこそCSS Modulesでいいはずです。ある特定のメディアクエリが使いたいとき、クラス名としていちいちmx:なんていう接頭辞を付ける必要は、CSS Modulesではありません。可読性もそちらの方が高いでしょう。

なお、Tailwind CSSで書いたスタイルの再利用性が低いとの批判は、私は本質的ではないように思っています。再利用するのはコンポーネントで、スタイルではありません（し、クラス名でもありません）。同じスタイルを使わなければならない場面とは、同じコンポーネントを使わなければならない場面でしょう。

ではなぜTailwind CSSが流行っている（もしくは流行っていた）のか。きっとこれには従来のBEM命名法にあった面倒が関わっていると思います。つまり、「セレクターの詳細度を常に意識して、一意でわかりやすい名前によって名前空間を分けなければならないストレス」があったのだろうと思います。けれどこれはCSS Modulesが解決しました。コンポーネントごとに機械的に名前空間は分けられます。であればCSS Modulesで構わないのではないでしょうか。

Tailwind CSSの、CSS ModulesやCSS変数に対する優位性がわかりません。少なくとも今はまだ。いつかわかる日が来るかもしれませんが……。