Writing CSS in Javascript brings back memories of pre-2000 web development, table based layouts and more horribly inline styles inside HTML tags. CSS was a breath of fresh air, it meant separation of concerns.. HTML the content and CSS the visual representation. With the advent of jQuery it allowed separation of behavior as well.
With frameworks like React these days, content+behavior is in JavaScript already, and with writing CSS in JavaScript, we've gone back 1.5 decades I think.
I had this same initial reaction, but concluded as others have that this architectural approach was not actually a separation of concerns but merely an unwieldy separation of technologies: http://blog.andrewray.me/youre-missing-the-point-of-jsx/
When you start thinking in components it becomes much nicer to have the styling, logic and layout all in one file, isolated from the rest of the application and easy to edit, move around and apply to any page.
The previous 'best practice' of having these coupled aspects in separate files now seems quaint and tedious.
There are of course trade-offs, and CSS-in-JS has not triumphed yet, but if you've held off from considering this approach simply because you've had 'separation of technologies' drummed into you in the past you might be missing out.
CSS isn't separation of concerns, it's just separation of filetypes. The problem with inline styles was that you had to repeat them all over the place. This is not the case with Javascript, since it's a programming language and it has an import system. I feel like the sentiment that JSX and JS CSS break separation of concerns is cargo-culting what separation of concerns is all about and why it's useful.
With frameworks like React these days, content+behavior is in JavaScript already, and with writing CSS in JavaScript, we've gone back 1.5 decades I think.