The time wasn't right until React + JSX taught us it is.
That is because developers are also just humans after all. Misunderstanding is common. And our tools wasn't good enough to support mixing languages in the same file (ye few existed, and also we loved to create new faster template languages).
Separation of concerns was always used as separation of technologies - we all felt comfortable. Projects like jQuery and Wordpress showed us how bad mixing technologies in a single file can be. Spaghetti code was all around. We've tried to overcome that misunderstanding by creating templating libraries. A mixture of 2 languages. We all liked it.
Since React + JSX and tools like Babel.js or Atom, it's easy to put all the view logic in one file. No need for a template language anymore, that can be parsed by our <programming language> compiler/transpiler in our IDE.
Now IDEs can detect multiple syntaxes in one file and support with code highlighting and error detection. And also, older IDEs and Editors have become useful thanks to plugins or CLI tools.
The time is right to keep code where it belongs to.
Just as inline styling and inline JS is bad practice, so is is inlining HTML in your JS. Same goes for mixing HTML inside you PHP or for mixing Java code inside your JSP tags via scriptlets.
If you look at why MVC was created in the first place, it was created to seperate view logic from business logic from data logic, same goes for MVP or MVVP or whatever they're called these days.
The general design principal is called Seperation of Concerns
The value of separation of concerns is simplifying development and maintenance of computer programs. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently. Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections.