I really want to agree with this, but the trouble is that an unstated prerequisite is that you need a team of developers that have a strong sense of software de

I really want to agree with this, but the trouble is that an unstated prerequisite is that you need a team of developers that have a strong sense of software design. A sensibility I've come to believe is drastically in decline in more junior software engineers (though don't mistake this for a statement that the quality of these devs appears any less). 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.