Here at Google, one of our most popular microservices frameworks enables microservices to be assembled into servers. If one microservice calls another one in the same assembly, it won't touch the network, and is quite optimized. There's no reason that microservices have to all run in separate binaries, but when it's useful it can be done easily enough without having to change your code.
I find my self doing the opposite. I’ll often create a Cloud Task that will call the same server that created it, just to make sure that another container will get spun up to handle the load if needed. Using Cloud Run this way quite happily for a mix of OLAP and OTAP workloads.
Yes, it shifts communication to over the network, but this comes with the benefit of making system boundaries much clearer. It's been my experience that this can allow different parts to evolve separately and make the choices best for their own needs, which can sometimes result in a paradoxical reduction of complexity as one all-in-one system turns into a series of simpler tools. Suddenly the part of the system that does background ETL work and the part of the system that serves up the admin panel can use different tools.
I will agree that networks are inherently complicated, but your system or systems probably use networks anyway. Using them internally often forces you to grapple with the complexity you were already facing. Plus, it's been my experience that networks are easier for most to reason about than shared memory and mutexes.
Let's not forget providing an easy set of dials to turn to scale a given part of the system. That's a point of complexity, but it can be an immensely useful one. Complexity is not always the enemy - a power drill is more complex than a manual screwdriver and this complexity is pretty useful.