I think this for me is the gist of the problem... A lot of corporations prefer these large monolithic codebases, with a thousand different interfaces and abstract classes.
I think this is a mistake in design, and prefer simple applications with simple interfaces. They are easy to maintain, and are more reliable as their are less moving pieces.
I'd rather write a small app/service in python, c, JavaScript than work in some horrifically gargantuan and abstract Java code base.
This is a problem with enterprise in general, they'd rather incur technical debt to stuff in new features into legacy monoliths, instead of designing small applications and services with simple interfaces.
A classic example is defining your services in interfaces with a separate class for the actual implementation. This means that even for services that will only be implemented once, you now have the class and an interface. But with an IDE (and since the mappings are clearly defined, I'm sure this wouldn't be a monumental task without a GUI), you write the interface, create a class to implement the interface, and the IDE generates your methods. That's minimal overhead for an IDE, but it require a bit of work on your part to manage in something like vim or emacs.
It really depends on how much resources your company has, what you're trying to do/prove/show, and how long you have to do it. Google gets idolized for their software, but the reason they can have so much perfection in their software is the amount of money their core business throws off, not the other way around.