The problem isn't that building clean monoliths is hard but rather that building messy monoliths in tempting.
Microservices, in most patterns, or even SOA will put more-than-arbitrary separation between code and databases. Without that more-than-arbitrary boundary then code gets spoiled because it's easy to import the other services library directly, it's easy to make that DB call yourself rather than route it through another controller, etc...
If you're in a monorepo then you're replicating the constraints a monolithic architecture applies, so yes, I could see that happening.
Edit: Inadvertently, this is why I also like to call these things "patterns" rather than architecture. Architecture being the idea, and pattern how you implement it.
Depends in which stage you are, but if you are still figuring out what to build, or how to build it, fast-built messy monoliths are the least of your problems.
Once things are validated, opportunities compound to rewrite "properly" (^Wtemporarily) things around or aside the monolith.
Exactly, in any moderately sized corporation new functionality will be rewritten several times, sometimes deprecated/reshuffled completely and crystalized after some time – that is good moment to start thinking about extracting things. Changes on the service boundaries are much more expensive than internal changes.
I never got this kind of line of argument. It's also easy to write bash script which deletes everything, write infinite loop in any language, create oom, add sql injection, have exponential complexity etc. - so what? If people don't have time to organize code, introducing microservices won't magically solve those problems. They'll end up with poorly done microservice spaghetti with tons of extra complexity/consistency violations all over the place. Now the architecture doesn't fit into single screen anymore and it feels it's simpler because you have separate screens for each part - but simplicity will be just an illusion.
It's just a matter of incentives and how hard it is to do the right thing, or hard it is to do the wrong thing.
If you gap services or microservices by a Git repository, then it makes it harder for them to import each other's code; you also will probably have code duplication. If you have repositories for the shared code that's safe then you have new overhead problems. If you keep them in a monorepo then it's just as tempting as in a monolith to cross domains; the only inhibition is resistance to ease of access and the only way to catch it is in code review.
These are all tradeoffs. Fwiw, I still run a monolith project, and part of code review is checking imports, and part of our documentation talks about shared code standards and locations. It can be done, there's just no natural guard rails present.
Microservices, in most patterns, or even SOA will put more-than-arbitrary separation between code and databases. Without that more-than-arbitrary boundary then code gets spoiled because it's easy to import the other services library directly, it's easy to make that DB call yourself rather than route it through another controller, etc...