Just take Ruby on Rails, which is probably a great example of a framework that runs into the problems you're describing. My experience with more contemporary, generally more junior, dev teams is that the "Rails" part of the framework is essential for these developers to maintain any loose semblance of adherence to any kind of architecture or design principles.
Earlier in my career I remember, even junior devs, spending a fair amount of time thinking about about the abstractions they were using, making design decisions, and often times being more guilty than not of over thinking abstractions.
Today I've seen so many very bright and talented engineers whose sole view of good software is minimizing the time from request to PR (and code reviews that strong favor minimizing the time from PR -> prod).
If you have a bunch of senior engineers (not SV "senior", but truly experienced), and they're the type that still pick up SICP form time to time, or spend a Saturday reading a section of TAOCP, then sure I think the framework-free approach is best. But you also don't need to tell that to a team of engineers like that.
Otherwise, frameworks and even languages that do the most handholding when it comes to design decisions are going to remain essential.