I feel like a lot of this boils down to a variation on Greenspun's Tenth Rule: "Any JavaScript-centric web development framework contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a web browser."

"I can add, change and delete CSS without any unexpected consequences. My changes to the styling of a component will not affect anything else. If I delete a component, I delete its CSS too."

This is readily achievable with ordinary CSS. Selectors by ID/class have existed for multiple decades. A Ctrl-F for said ID/class name should be pretty painless to do even in the case where you're doing everything in one giant spreadsheet (though in this day and age of CSS preprocessors, no reason why you couldn't have widget.js and widget.css, the latter of which gets compiled into the final spreadsheet as part of the build process).

"Never go on a hunt for CSS affecting your components ever again."

I'd hardly call Ctrl-F a "hunt". JavaScript can't fix bad code hygiene/organization.

"I cannot expect all team members, particularly juniors, to have an encyclopedic understanding of CSS."

So you expect them to have an encyclopedic understanding of your CSS-in-JS library instead, then?

Or perhaps it'd me more reasonable to be okay with looking things up every once in awhile?

"With CSS-in-JS, we automatically sidestep common CSS frustrations such as class name collisions and specificity wars."

I'm curious how much these are actually problems in the first place (or at least problems inherent in CSS itself), and how a CSS-in-JS framework expects to solve them without completely reinventing the browser's styling engine.

"This leads to a marginally slower time to interactive, but a much quicker first meaningful paint!"

If you didn't try to do everything with a giant blob of JS, you wouldn't have to do these kinds of ridiculous tricks to reduce time-to-first-paint.

"Send only the critical CSS to the user for a rapid first paint."

If the CSS is not critical, then it shouldn't be sent at all. No reason a backend framework couldn't selectively send only the CSS relevant to the HTML being sent.

"Simply style your components with a global theme or based on different states."

<foo class="widget primary"></foo> <foo class="widget secondary"></foo>

So difficult.

"CSS-in-JS combines all these benefits into one handy package and enforces them."

Yes, at the cost of needlessly reinventing stylesheets and making it significantly more difficult to modify the styles downstream (e.g. for accessibility reasons).

"Thousands of companies use CSS-in-JS in production [...] (including this website)"

As an experiment, I switched JS off for that page and refreshed. The styling certainly doesn't seem to be happening client-side. Instead, the HTML source contains a bunch of obfuscatedly-classed divs and a giant obfuscated stylesheet in an inline <style> tag.

Surely JS is not specifically needed to achieve this result. This could've been done with CSS-in-Python or CSS-in-Ruby or CSS-in-C or CSS-in-Lisp or CSS-in-COBOL or CSS-in-Brainfuck or whatever. It also could've surely been done with a dedicated language-agnostic CSS preprocessor. Further, it could've been done the "hard" way (not really hard at all) with CSS selectors alone (since that is indeed the end result).