The two videos have many valid points in them.
One thing that seems to be misunderstood about “vanilla css with custom classes”, when people invoke the adage “naming is the hardest part …”, is that semantic class names are not meant to indicate the presentation, they are used to indicate meaning (not what it looks like but what its purpose is).
In this way, the argument that is often used that says “When you use custom classes in your html, you can’t immediately see what they do” misses the entire point. It’s this abstraction that gives them power in the first place!
The original benefit of using semantic classes in separate CSS files and referencing those in the HTML files, is the separation of concerns obviously, but part of that is that any changes in the CSS do not require updates in the HTML.
When you have 1 or 2 html files, updating them when styles change isn’t a big deal, but when you have a larger site (100s or 1000s of pages), then this separation of concerns is the only way to make maintaining and updating the site viable without some form of automation.
Cwicly offers its own ways to address this (regeneration of html/styles, etc) and Tailwind also partially addresses this for some of its classes (the ones without numeric values), for example being able to modify the underlying values in sm, md, lg, xl classes via the config.
Also, for any projects that are edited only within WordPress / Cwicly, many of the arguments against Tailwind don’t apply because we are not manually editing the HTML and it is managed by Cwicly automatically.
Admittedly, when I see the HTML output from Tailwind, whilst I know the benefits, I find it very clunky to look at and would prefer clean semantic classes in the output, however I am willing to put aside my personal preference when needed to explore the potential benefits of the workflow consistency when working in a larger team.
Some of the considerations raised in the discourse are very important ones, such as this one from @T-low:
It will be good to find an optimal approach to customising the Tailwind config that allows maximum reusability of existing Tailwind examples.