The thing is, React works with plain CSS too. I think a lot of newcomers see that JSX looks like React-flavored HTML and naturally assume that React will have its own flavor of CSS, but it doesn’t. There are libraries for CSS-in-JS of course, third party ones. But implementing :hover on a button in React can be done just the same as in plain old HTML - with a bit of CSS in a .css file. Or for active/inactive states, you can use template strings to set a dynamic className, and target that className in the .css file.
That doesn't change the reality that there are a million projects out there using css-in-js - about 50% according to developer surveys. I doubt they are all written by newcomers.
The fact that React is a plain view library and doesn't provide / interfere with the rest of your tooling is precisely the problem in my opinion, and does not exempt it from the resulting mess. The lack of standards has led to the proliferation of a thousand supporting libraries, all special in their own way, in turn making the definition of 'good practices' nearly impossible; it also gives way to flavour-of-the-month development practices, where popularity (and not necessarily quality/fit) determines what libraries most people use. Similar discussions can be had around SSR, accessibility, bundling, compiling, code splitting, animations, component APIs, state management, persistence, fetching data, and so on.
Even if you do use a CSS-in-JS solution, which i'm not a fan of but have used in a few projects, they still don't do "hover in js"!
All they are are just fancy wrappers around putting more or less the same straight up CSS into the page. So you still use :hover or :active or whatever to do the appearance states in straight up css.
I still fail to see how React encourages adding event handlers to add hover appearances. A developer who thinks that's what to do with React was going to fuck that up with any technology.