To start with, the only good way to do CSS in JS is to use a library that compiles your styles at runtime and inserts them into the document under a style tag. If you're not doing that, you lose the ability to use pseudo-elements and pseudo-selectors like hover. Probably 95% of the time, using CSS will be easier than setting up an event system to monitor all of this stuff yourself.

React's default tutorials will almost always tell you to pass styles manually into components, and ironically this reintroduces a lot of the problems with cascade that we're trying to avoid, because it's very easy to apply multiple styles in the wrong order or forget that some style is getting overridden. It can also make it very difficult to figure out where styles are coming from in code. So definitely don't follow that advice -- at the very least use a runtime compiler that doesn't spit out any inline styles.

There are plenty of libraries that will handle runtime compilation, but many of them come with performance costs. Enterprise software has a reputation of being slow, for good reason -- it usually is slow, because it's framework heavy and handles weird edge cases, and it's developed by multiple people over multiple years. I worry about performance more at work than I do on personal projects.

Aside from performance, I was finding that it was irritating to track class prefixes for dynamically compiled styles. One advantage of BEM is that it's really, really easy to debug. You always know exactly where a style is coming from, you always know where in code to find it, and you always know what class to use in the (hopefully rare) case that you need to hack together some selectors someplace in your code.

On the ecosystem side of things, there are a number of tiny annoyances if you're using React -- Webpack can handle live style updates if you're compiling a stylesheet. If you're compiling your CSS in Javascript though, Webpack can only reload the entire page. I found this made iteration and design a lot slower. Maybe there's some setting someplace to fix that behavior, but I couldn't find it and I didn't want to waste the time trying to build my own solution.

Finally, on a personal level, I was finding that putting my CSS in the same file as my component logic was making it very hard to organize everything and quickly grep sections of the code. This is probably personal preference for a lot of people, but I've found that disorganization is one of the biggest risks for large applications. Everyone tells me that you can still keep your JS-styles in a single file, and people will be good, and they won't split it across multiple sections of code or files -- I don't think that reflects the reality of most software development. I want the people I'm working with (and myself) to fall into a "pit of success" where organization is concerned.

Putting all of that together, the biggest thing was that I was messing around with all of this technology, finding that it was not as tightly integrated or as seamless as everyone said it was, was spending a lot of time debugging stuff, and I asked myself -- why?

IMO the biggest problems to solve with external CSS is style cascade, it's conflicting class names, it's selectors that apply across multiple components. BEM solves all of these problems for most codebases I've encountered, and doesn't require any extra libraries or frameworks. I hate debugging third-party code, and I can count on one hand the number of third-party libraries I've used on the web that I've never needed to debug. So a solution that solves all of the problems we face at work without introducing edge-case behaviors or extra dependencies is nearly always the right choice to make.

There is a rare case where you want to make your own custom CSS behavior that can only be handled through Javascript, but this is usually a bad idea because of performance concerns, and it's usually better to handle that as a separate, global polyfill anyway.