No matter how careful you are with the initial architecture of your microservices system, it is inevitable to re-architect as you go. Specifically to properly distribute service responsibilities.
in some organisations the amount of meetings and overhead scales proportionally to the number of network connections in the architecture diagram, so that also suggests replacing external dependencies with in-process function calls wherever possible.
Isn't this true for all software systems? If anything, microservice architectures just make it easier to re-architect parts of the system, thus lower the bar to actually do the work.
With regards to stuff inside each service, microservices aren't really different from monoliths.
When service calls are involved, I'd argue that microservices make it even simpler to refactor/rewrite modules and entire services. Microservice architectures already impose boundaries between components that help limit the scope of any work, and teams are free to deploy and run in parallel, even in production, any service they wish to update/rewrite/launch. You can control which service is called with a load balancer, and don't bother much with the services you're developing.
Each microservice is owned by a different team, so if you need to change something that touches 2 or more, you need to collaborate with other teams...this adds a lot of overhead. Not to mention that it becomes almost impossible to do real re-architecting: you can't really move data flows or code from one microservice to another. In my experience you're more likely to end up with duplicate flows, duplicate code, just because it's too damn hard to move "class X" from A to B. In a monolith you can and often do those kinds of changes.
It's also easier to have unit tests. It's easier to have integration tests that are still fast and self contained. Sure, you might say that unit tests are easy to write in any scenario but what I mean is maintaining them becomes easier, especially if you're doing Detroit style. It's easier to not break them when doing larger refactorings.