And what about a monolithic system executing thousands of different functions?

If your app is a simple todo list, sure, go monolithic (but you should still delegate storage to some other tool). If it is much more complex than a todo list, then it is very likely that you have many packages containing many modules developped and maintained by many programmers. And if one glitch on one side of the monolith affects a remote module and functionalities depending on it, or even breaks down the whole monolith, then you should go microservices. Or split your code base. Or do whatever is needed so the thing can still move forwards, if slowly, without breaking apart at each little step.

Seriously though, all of the problems breaking the system up will be blamed on people who already left the company, whether they deserve it or not, and the patterns that keep you in a monolith will continue on forever.

The only solution I've seen sort of work for this is to make a single binary, but create modules with extremely clear boundaries. Even so far as compiling them separately if the language is statically typed. But even that can go sideways the moment someone builds caching into the system.

I've come to appreciate why external caches are so popular, but for my money I prefer caching at the HTTP layer. You have to solve all the same problems, but you get one level of cache for free, it's easier for QA to understand, and it puts cache eviction in the hands of mature pieces of code that all implement the same spec (which might account for my previous point).