Okay, Craig, you can have your monolith back when you can get your engineers to care in the slightest about keeping the codebase organized instead of turning it into a big ball of mud. I'm talking encapsulation. I'm talking well-defined interfaces that aren't glued to specific implementations. I'm talking some sort of dependency inversion, dependency injection, service locator patterns, any of that. I'm talking real use of the single-responsibility principle, all that software-engineery stuff that everyone ignores. Because I understand what you're getting at 110%, but by and large, all this stuff doesn't happen otherwise.
Until then you're going to have these things forced on you by your local Architect, forced on you by running a bunch of separate processes on separate containers with DNS as the cluster's service-lookup framework.
I'd rather have one codebase that's a big ball of mud than 10 mini balls of mud that combine to make one immensely complicated ball of mud. At least a stack of messy method calls is much easier to debug than some data that travels through 5 different systems before it gets to the user.
How about, you can have microservices back when the engineers/architects care in the slightest about defining domains between services and having a direction or overall idea for how they communicate.
It's easy to get to a point where you have a big ball of mud of 100 micro-services where each new features touches 20 of them, and just hack in whatever new APIs everywhere that's needed to push a new feature out (but probably buggy due to async state and race conditions that noone was trained enough to figure out up front).
All that is pretty equivalent to what you talk about with monoliths.
Until then you're going to have these things forced on you by your local Architect, forced on you by running a bunch of separate processes on separate containers with DNS as the cluster's service-lookup framework.