React components only ever contain view logic, which already solves a part of the problem. Furthermore, you typically split that logic into multiple components, many of which are stateless, independent and small.
Let me try and cover some of the reasons why. I'm sure you know about these reasons (and can probably list more), my goal is just to present an example of what I consider to be a straightforward logical explanation:
If domain/business logic is mixed with view logic, then it would not be possible to reuse the same logic in a different view. These changes happen more often than anticipated: for example, a PHP project that has the view logic separated from the domain/business logic can more easily get an API (a HTML is one view, a JSON API would be just another view)
Additionally separating database code from business logic lets you switch databases more easily or to give you multiple ways to access the data. For example, data may be directly fetched from an SQL database initially, then its determined that this is too slow and results need to be cached in Redis. If there is no separate code for the data access layer, you would need to locate every database query and make sure it queries the cache first.
So this is what qualifies as a straightforward, logical explanation for me: lets assume the opposite statement was true, then we demonstrate how this leads to a bad situation and why its bad (more bugs, more work, and so on).
Another would be doing a case study: we did X (mixed business logic and templates in this way), then when we wanted to do Y (present a different view V) we had to not only write new code (for the new view) but deal with this problem (uncouple the existing logic from the existing view). If we originally did otherwise (wrote the logic separately) this would've been the same or similar amount of work (demonstrate this) yet later we would not have to do the hairy decoupling (which took Z amount of time and caused N bugs)
I think the whole industry would do much better if we focused more on actual specific examples and case studies of problems and drawbacks of different approaches rather than giving vague descriptions of the current state and claiming its "bad". Its just not helpful at all. There is so much reinventing the wheel in our profession simply because we are not communicating knowledge effectively. Frankly, most of it reminds me of religious dogma.
Apart from here it is again...
So...like PHP, then?
No, because PHP still work that way (hypertext pre-processor) and Yes because, PHP has frameworks that makes PHP work like other solutions (Ruby,Python,Java + frameworks), but one still need a <?php on top of a file.
And again, a lot of PHP developers despise these frameworks and question their usefulness. In theory, they are right since PHP is a template language which goal is to render text content, and separation of concerns can be easily achieve without a complex framework in the case of a web application. In practice a framework makes large codebases more maintainable, no question.
PHP is a strange beast. It's somehow rigid like Java, at least more rigid than most dynamic languages, it's a dynamic language, and a template language and it keeps on getting stuff from Java like languages (PHP 7).
It's ironic that PHP was created because its author kind of found Perl too difficult to use for web dev, then wasn't taken seriously by pros then tried to imitate Java in some ways to feel more professional and now is on part with Perl in terms of complexity, while half of the PHP community praises over engineered codebases often found in the JEE world.
I can't dump html into a .rb or .js file, so I'm less likely to do so as a beginner. On the other hand, starting out with php, that seemed like the logical thing to do. Because I could.
I think what the commenter is saying is no one builds like this anymore in PHP, regardless of whether or not you're using a framework.
Graphic designers were expected to know HTML/CSS while developers focus on PHP.
While I'm not entirely sure what the original reasons were, I can see a big difference between the way, say, PHP was embedded in HTML and now JSX is embedded in JavaScript:
1. PHP was embedded in HTML, not the other way around.
2. The preprocessor basically concatenated everything as strings without caring about what DOM would end up being a result.
Because of these two reasons it was extremely hard to protect against improper injection of data into the resulting HTML. There was no way to make the preprocessor understand the different types of "placeholders" in HTML and what kind of data should be allowed within them.
In contrast, JSX embeds HTML within JS. Furthermore, JSX (pretty much) compiles to function calls, not string concatenation. This means that the engine has great degree of control over the interpretation of the data: its impossible to get malformed HTML, or for an attribute value to escape the actual attribute and so on. Which in turn eliminates the original problem that was present in PHP.
As for separation of concerns, thats still possible with JSX. We have CommonJS (or ES6) modules and we can move the render functions anywhere we want. But now its up to us to decide whether it makes sense or not.