In the first part, I've tried to explain what CSS-in-JS is nothing more than a style delivery system, not style system, and you actually don't need it.
The question - why do you actually need?

What's the goal?

There are 3 things you might need:

• ship the result as fast as possible. Bussiness would appreciate. Common rumours usually tangle CSS-in-JS and Dev speed, however, I am not sure why they are tanged.
• make something reusable. Like build your own UI Library (everybody builds their UI Libraries nowadays), and by some reason it's like HAVE TO BE written using CSS-in-JS. Don't ask me why.
• share that UI library across different product and teams.

There is also one, or two more things, which you also need, but they were not present in the list above, and the majority ignores their absence.

• client side performance. It should be fast. My kids still use IPad Mini 2 (5 years old), my mother-in-law uses some laptop which was cheap 5 years ago, and not it's almost not working...
• server side performance. It should not cost you much, as well as SSR is working better then it's FAST.
• you should understand what you are doing, and how it would work.

And actually, the last point is the most important one. And it's not bound to CSS-in-JS or -CSS.

I urge you to ​read this presentation - Crafting Stateful Styles - about rethinking WHAT to write inside CSS. Like one more methodology.

Let's go deeper

Your style is not a collection of props

 color: while
 {(props) => props.isPrimary && `color:blue`}

Sounds familiar? Sounds terrible! There is no way to predict how your styles would look like with some random set of props, and many different combinations are possible.

BEM(CSS) as well as trousers(CSS-in-JS) has an idea of "modifiers" which are a more "static" and predictable way to handle complex styles.

Reusability is about separation

This is something people are usually missing in CSS-in-JS - a "methodology", like SMACSS, BEM and visa versa.
And the core idea of probably all those metodologies (but not technologies) is separation - a separation between Block and Elements, as well as State and Theme in SMACSS.

Every element would be "constructed" from different style pieces, and expect you do add a few more pieces to complete the picture.

For example in BEM terms Button is a Block. And Block may not define dimensions. That leads to the expectation that you will consume Button as an Element of your component. And Element might define dimensions.

Block styles are meeting Element styles and forming a Voltron

In JS we are talking about reusability, composition and all that stuff. In CSS there is the same stuff, just use it.

Conclusion​

CSS is not your friend, and CSS-in-JS is not your foe. People saying you should use X, but not Y - are your enemies.​

And all the people saying you should use CSS-in-JS, not CSS are just victims.

It's not about the technologies, but about the way you use them.
About the reason to use in one or another way.

• are you getting any feasible improvements from Y
• are you sure, any number or at least theoretical proofs?
• what would change in a year? I am speaking of tech debt.