This has been going on forever. 3-tier client-server code bases had problems separating "presentation logic" and "business logic" because often they're very very closely connected.

React runs on the client. It runs the logic needed on the client. And there has always been some logic required on the client, otherwise you end up refreshing the screen for every.single.validation. which is a total PITA.

Given that there's some logic running on the client, then maybe running more of it there would be a good thing. This is the principle behind SPA's after all, and they've turned out to be a Good Thing generally. Not suitable for every use case, mind. So do we then need a separate Logic Layer for logic that isn't to do with Presentation? Where do we draw that line given that the whole thing is running on the client? How do we keep the thing clean and stop bits of logic being run on random button events?

React makes perfect sense when you look at it as an answer to the problem of "how do I add logic to my presentation layer and not end up in a mess of spaghetti code?"

And how often are the presentation and logic changed in isolation of each other... they aren't separate concerns at many levels. The concern is sepearated in React at a component level... how a component is rendered is just as important as how it raises/accepts changes outside of itself, and often interacts.

Also, having JSX in my JS is much easier to deal with than remembering some abstract DSL for how to iterate through children in a template language. It's no more goofy.

Anywhere from never to always. A Pure logic change shouldn't need a ui change. At some companies the ui and logic are different responsibilities (this used to be common). Other times there will be multiple UIs for the same logic.

React is for UI logic, application logic may be in a different place.