Any non-trivially sized software system will use a framework to avoid code duplication. You can either choose someone else's framework, or roll your own, but unless you're a framework design wizard you're unlikely to build an all-purpose web dev framework which beats the well known ones.
Which is to say that I definitely recommend that everyone at some point develop their own all-purpose framework, because it's a great learning experience, but if they're doing production work they should stick to one of the existing ones, even if it's just so other developers will have an easier time understanding the codebase.
How do you explain the mountains of code written before the great frameworks saved us all? Is it all bad? Is it all an ad-hoc framework? On all of the framework-less projects I've worked on, what emerged was significantly better than a framework: it was a real domain model that was decoupled from all of the irrelevant technical details.
I know, nobody does that cause it's hard. The frameworks certainly don't help.
You can write great software without MVC, or frameworks, or OOP. Frameworks are often crutches for people's anemic design skills. They're not nearly as important as everyone thinks. You can easily coordinate multiple people working by, you know, sketching out an architecture amenable to he division of labor.
Yes, it is all an ad-hoc framework. There are no large frameworkless projects. Programming languages don't come with enough abstraction to model a large domain (unless you're using a 4gl, but those are semi-frameworks). You always end up building or reusing additional abstractions, and those collectively are a framework. The framework can be procedural, functional, declarative, oop, mvc, or any of dozens of additional buzzwords, but you cannot avoid having one.
Anyway, my point is that if you're working on a non-trivial solution in a problem domain that other people with good design skills have built frameworks for (like web dev, the most oversolved domain in software, aside from text editing), it doesn't make economic sense to roll your own. Even if you have the rare trait of good design, the productivity benefit for yourself by having a more closely adapted framework is washed away by the cost of building it and having to bring other people up to speed on it. I've had the experience of lots of home-grown framework code, and rolled my own quite a few times, and the longer i've had to observe other developers working on that code the more convinced i've become of NIH being a programming anti-pattern. It can make sense to roll your own, but for the majority of web dev programming it doesn't. There may be categories of software dev where the statement inverts though, i'm not going to generalize too far.
What i however also think is that many of today's frameworks are overengineered and force you to write too much code to solve a problem. They suffer from tdd-induced design damage, as dhh would describe it (the recent discussion between fowler, beck and dhh was enlightening). Many frameworks have optimized for secondary goals like orthogonality or compliance to design patterns instead of primary goals like fitness for purpose, speed of development, maintainability, and usability of the resulting product. However, i'm of the opinion that even given all that, for general web dev and for most people, it's better to use one of the common ones than to roll their own. They'll build a more maintainable solution in less time.
Which is to say that I definitely recommend that everyone at some point develop their own all-purpose framework, because it's a great learning experience, but if they're doing production work they should stick to one of the existing ones, even if it's just so other developers will have an easier time understanding the codebase.