I believe a simpler explanation is that it's easier for some devs to cleanly separate concerns when they're forced to do so by the constraint of process separation, rather than language modules/packages, where it's too easy for a junior dev to break the architecture with a single import.
Keeping a monolith's concerns cleanly segregated does require a small amount of discipline.
I would propose that an alternate explanation is that when the processes are actually separate in deployment, you filter out strong personalities (or management types who are overly involved in things outside their area) from dominating the development process as well.
Stopping someone working in one area from deciding they just don't like the look of the other is a benefit or all its own.
>it's easier for some devs to cleanly separate concerns when they're forced to do so by the constraint of process separation
This is a dangerous ideology. Process separation doesn't enforce loose coupling, it simply makes the pain of tight coupling between them that much worse.
I worked on a "microservice" system once where I regularly had to debug a problem across four different service boundaries and two different languages. It felt like I was using boxing gloves to perform surgery on a rube goldberg toy.
Conway's law explains why that discipline is harder in practice. If everything about the business suggests that two things are tightly coupled, then naturally someone is going to make that import.
Keeping a monolith's concerns cleanly segregated does require a small amount of discipline.