You never
needed a framework until recently when you had to deal with the conceptually disjoint modern web and the pile of languages it takes to do anything reasonably complex. We never had to use frameworks when writing against Win32, Swing, iOS, Android, etc. Certainly, there were frameworks -- such as MFC. But they quickly fell out of favor because the structure they imposed wasn't helpful at all. (Way back when, we figured out that the framework superclass is an anti-pattern.)
Win32, Swing, iOS, et al aren't really frameworks in the same sense that something like Rails is. Win32 doesn't care if you name your code something that clashes with The Revelation Given To Great Prophet DHH; all it cares about is that your WNDPROC behaves like it should. The OO variants of this only care that you derive your UI classes from the framework's classes so you can be notified of relevant events. Nor did these old 'frameworks' (as often incorrectly stated) prescribe the underlying architecture. They didn't force you into MVC for every single project, they didn't force you to use a database for persistence.
Monolithic frameworks are a modern fetish; borne out of a Stockholm Syndrome for the Business: "how will we hire easily replaceable workers?" / "how will we spin someone up in the minimum amount of time?". The answer: programming by MadLibs.
Developers advocate for them because they provide immediate gratification for doing very little work. They confer a mediocre architecture on all projects, which is perceived as preferable to the hard work of designing and architecting a system from scratch. They are a form of blame-shifting by developers: they can offload some of the risk and the Hard Parts of development to a Smart Person/The Community and run to them for help when it breaks. This is not a bad thing, but it does stunt the design impulse, and limits their growth as developers.
In the case of Rails, choosing Rails is no guarantee of project quality, or even conventions. Are you using Postgres, Mongo, or a combination of data stores? If it's the latter, then AR's transactional niceties are out the window! Are you using regular Rails views, presenters, or decorators? When you structure your controllers, are you using The Rails Way (fat models), or services, or more Bernhardt-esque design (app lives in lib/)? All of these things require spin-up time to learn the where and the why.
I do think frameworks are a symptom of propping up conceptually weak abstractions (e.g. the web) and languages. It should be concerning to you that all the metaprogramming in the world + a fully dynamic runtime cannot produce a framework that makes it easy to produce minimally coupled run-of-the-mill business software that doesn't require horrendous hacks like Rails' Spring.
Buy a copy of Growing Object Oriented Software, Guided By Tests. The author builds something sans framework, letting the construction of the software guide him to the best design. The resulting software is lean, supple, and easy to extend.