Faster development time

The main benefit is faster development cycles. One uses code that has already been developed and tested, no need to write the same boilerplate code for the umpteenth time. Code. Just. Ready. To. Be. Used.

More reliable code

It’s said that the best way not to product bugs is to not write code at all. But since code needs to be written anyway, I personally prefer code that is already battle-hardened. The fact that the code I’m using is also used by a lot of other developers make it more likely that most bugs have already been found, and fixed.

More focus on business code

While most of the boilerplate code is taken care of, that leaves more time to create code that actually focus on resolving business problems. Are you really up to code your own testing framework? If yes, what about your own persistence framework? I’ve seen it - "because those Hibernate guys did really a crappy job". Obviously, developers who weren’t part of the decision and who ended up maintaining the custom proprietary "framework" had a very different opinion of their respective merits. Usage of a container also allow useful features, such as monitoring, out-of-the-box. This is already the case with the Spring Boot actuator, and soon will be with Microprofile.

Easier change from one company to the next

I’m old enough to have been developing when there were no frameworks. Or to be more precise, no Open Source framework. Because the abstraction level of most API is too low, most companies did write their own framework. That meant one had to learn a new way of doing things for one company to the next. The ramp-up time of every new developer entering the company was disastrous. And whatever framework one learned in one place was just a loss of time regarding employment in other places. Using a limited set of frameworks makes knowledge reusable.

Improved employability