Rails was crap. Spring * was crap. None of the back end frameworks came close to thinking in abstractions - code reusability was an afterthought at best.
Ask yourself, why was there never a Rails component library? Because Rails made abstraction difficult in the front end. Nobody did a good job here.
Partially, but let’s not pretend our field is more rigorous than it actually is. Most it was following fads: the cool kids at some big tech companies were building HUGE apps with tons of logic as SPAs and a lot of people wanted to say “us too!” without considering how similar their apps are or comparing staffing. The natural arc I’ve seen is that teams who didn’t pick an SPA for solid technical requirements end up delivering results which are no better at considerably slower speed because they’re supporting a lot of non-domain complexity and still end of changing their backends in lock-step with the front end. That tends not to leave time for things like accessibility or performance.
The honest truth is that we have had front end and back end developers for as long as the web has been around, and before that. Your "full stack" developers are most often back end developers who begrudgingly can put together a less complex front ends with very little understanding of what makes a front end good to work with. Your "full stack" front-end preferring developers get drummed out because the back end developers conflate being good at back end concepts with being good at programming in general.
There is a definite back-end bias with developers who do not specialize in web or mobile front ends.
For some applications, that's fine. However, back end developers build the back end frameworks and do not think about what makes a great experience for developing more complicated user experiences.
In many ways, the reason front end developers moved to SPAs was that they could better control their own tooling in ways that are difficult in the traditional web application frameworks.