Well, I don't like Tailwind and I admit that haven't use it.
I browsed a lot about it and read the rationale twice already (it's looks amazing how often this article has been cited in just this thread). And I got more away from it after first read, and even more opposed to it after the second read.
I maintain projects, across multiple stacks, and Tailwind just looks like it would be a nightmare to maintain in the projects I work and worked. I've played a lot with the https://play.tailwindcss.com/ and my objections are even greater. Repetition of classes would cause much more painful style changes. Debugging in chrome looks like a struggle. Cryptic class names that might be used by many other libs or even might be meaning completely different things in other than the current project, renders codebase modularity as not possible - if I want to take something and then show it somewhere else outside my project, I will have hunt for WTH is overriding my styles, just to figure out that one of the "py-8 text-base leading-6 space-y-4 text-gray-700 sm:text-lg sm:leading-7" (instead of "content-container"), means something else on target site and simple name spacing encapsulation does not work fully. The example page does not even semantic use HTML tags - which to me tells that "semantic" might be completely misunderstood by the lib author.
Simple design doc in the project would solve problems raised in the said rationale. Indeed - Tailwind seems to be a ready-to-eat design doc. The problem is that it is the same design doc for all people using it.
Those reasons makes me not even remotely tempted to try Tailwind.
Your objection seems to be: I can't move a component from a TW project to a non-TW project, and it would be difficult to combine a TW project and non-TW project. Is that a fair summary?
On the first point, moving a component from one project to another one that use a different CSS framework is sort of a weird thing to do. I've seen cases where people combine Bootstrap with a bunch of random personal styles, but I haven't seen anyone combine Bootstrap with e.g. Material design. ISTM if you're combining projects, you'll get a lot of CSS bloat and unexpected interactions.
On point two, you actually can tell TW to use a prefix, so instead of margin-left/right: auto being "mx-auto" it would be "prefix-mx-auto". Doing that would let you combine TW with another project that used the same class names (though obviously, you're going to have to go back and fix all the class names in an existing component).
TW's niche, ISTM, is for people who want to make small-ish, highly customized sites quickly. I don't you'll be happy with it if you need to integrate with a lot of legacy CSS. I also think if you don't really need custom styles, then you can just use Bootstrap/Material/Bulma/whatever and it will be much simpler than having to make all your buttons yourself or whatever. But for things like isolated landing pages, TW is great because you get an experience that is like writing a new CSS file, but quicker (no need to switch between the HTML and CSS or make up names) and better guided (preset variables for the sizes, colors, and breakpoints).
I maintain projects, across multiple stacks, and Tailwind just looks like it would be a nightmare to maintain in the projects I work and worked. I've played a lot with the https://play.tailwindcss.com/ and my objections are even greater. Repetition of classes would cause much more painful style changes. Debugging in chrome looks like a struggle. Cryptic class names that might be used by many other libs or even might be meaning completely different things in other than the current project, renders codebase modularity as not possible - if I want to take something and then show it somewhere else outside my project, I will have hunt for WTH is overriding my styles, just to figure out that one of the "py-8 text-base leading-6 space-y-4 text-gray-700 sm:text-lg sm:leading-7" (instead of "content-container"), means something else on target site and simple name spacing encapsulation does not work fully. The example page does not even semantic use HTML tags - which to me tells that "semantic" might be completely misunderstood by the lib author.
Simple design doc in the project would solve problems raised in the said rationale. Indeed - Tailwind seems to be a ready-to-eat design doc. The problem is that it is the same design doc for all people using it.
Those reasons makes me not even remotely tempted to try Tailwind.