> To me this says more about the development practices of that team than about BEM
Well you could say that BEM requires strict development practices to work well. This is could be a downside for many teams, seeing as this comes at a cost which grows as your team/product do. Organizational overhead is a significant factor when considering a technical solution.
> Meanwhile Tailwind is functionally equivalent to this:
It's a funny platitude, similar to the argument that "Tailwind is just like inlining CSS" but it's of course overly simplified. Variable support, hover/active/other states, and of course breakpoint-specific variants for all of the classes making responsive styles possible.
> Also since there's no composition, just by looking at the codebase it's not clear if a change is something that should propagate to other, similar instances or land only there.
Even with BEM, you usually store components in partials/templates to keep everything contained and to reduce duplication. So in this regard the composition is the same. You import a button in your code, you aren't writing out this every time:
Blah
The composition happens within the templates themselves.
EDIT: I'll follow up and say that the "composition" for Tailwind components works very similar to CSS Modules (CSS is scoped to a component, and delivered with the component itself), or StyledComponents (similar to CSS Modules, but built into the React component itself). But with a few more benefits:
1. Does not rely on a build system to bundle/deliver styles
2. Less abstraction; no need to create scoped classes even (in the case of CSS Modules)
3. Works outside of the JS/React ecosystem