It’s a cost benefit analysis that engineering should be able to make.
Unfortunately, people throw out processes that teach them how to actually plan and release 0-defect work, so they can’t begin to estimate the costs of any of their efforts.
I’m sympathetic to the desire for simplicity, fast feedback, purpose-built code, etc. And “no framework” is the right approach sometimes.
But for internet-accessible code, security is a Big Hard Problem. And frameworks have often solved, or provided simple ways to solve, a wide variety of security issues. See http://guides.rubyonrails.org/security.html, for example.
Writing your own framework means taking responsibility for not what the software does (which you can encode in tests), but what it doesn’t do or allow. It’s always the things you don’t think of that get you in security.
How do you assess and mitigate that risk without spending a lot of time on “waste” coding - building protections you could have gotten for free from a framework?