Yeah I'm pretty skeptical of the benefits. It seems like better isolation within your monolithic application solves a lot of these issues, no need for a network socket.
If you can't isolate things well enough for some reason, maybe it makes sense to have separate services (maybe run them all on the same machine, deployed at the same time and talk over a local socket?), but even then I suspect you just need normalservices not microservices.
Maybe adding the network socket makes the isolation within the code a requirement as opposed to a best practice. By this mechanism maintaining isolation is a requirement and not something someone can bypass "just this once" but fix it later.
There's a flood of blog posts (including this one I think) that have conflated the two, probably unintentionally. I'm happy that decoupling their systems worked out well for them. I'm not so happy this is fomenting a new fashion for creating unnecessary network API end points.
That isn't to say that you should always combine your services into one big mega-service. Just that dividing up services should be something you do only when it becomes obviously necessary and for good reasons unrelated to coupling.
If you can't isolate things well enough for some reason, maybe it makes sense to have separate services (maybe run them all on the same machine, deployed at the same time and talk over a local socket?), but even then I suspect you just need normalservices not microservices.