If it is a small team of close knit developers who communicate well, and expect to work together for a long time. Roll your own setup, loads easier and much more flexible.

If you are a corporation with reasonable dev turnover and good management, you might be able to pull off your own solution too.

If you are using contractors, have high dev turnover, a distributed team, and especially all of the above. Use a framework, any framework, otherwise you will wind up with a disaster within 6 months.

There was a really great talk a couple years ago about Twitter's defunct FlightJS framework. The framework was meh, but something in the presentation stuck with me, "If the shit is in a box, no one can smell it.".

I took that to mean that if your application is structured and organized ( like what a framework imposes ), suboptimal parts of the application will have a smaller impact on the app as a whole, and refactoring those parts is often a matter of just "throwing out the box".

On the front-end React has done a fantastic job of providing lots of boxes for contractors to shit in.