1) You have tooling.
2) Probably also shared conventions and libraries.
3) Everything is easy to find and run on single dev machine.
And no, monoliths almost never end up that way as long as they're internally modular. Services are just modules with less sharing and more overhead.
How many monolithic 1,000,000+ line code basis have you navigated.
1) That's true of both. 2) That can be true or false of both. 3) That's covered by tooling?
> And no, monoliths almost never end up that way as long as they're internally modular.
Well your caveat is literally the problem this post is discussing. They usually aren't.
You don't have to prove to me that monoliths are bad. I get it. (You don't have to prove to me that spaghetti is bad, either.) But you seem to have missed my point.
Monoliths don't just happen. They didn't just wind up in your server room because the roof leaked during rainy season. They didn't get delivered by FedEx by mistake, and your people went ahead and signed for them. No, the monoliths are there because people wrote them.
Why did people write them? 1. Because they didn't know better, and just fell into it. 2. Because they thought that was the best way to architect something. 3. Because they didn't take the time and effort to make something more modular.
People cause the monoliths. To fix monoliths, you have to fix the people problem, or you're going to continue to get monoliths.
You are doing the same thing OP did: Fundamentally misunderstanding the purpose of programming. It's an interface for humans to communicate with machines in a way that makes sense to humans.
If monoliths always end up being unmaintainable pieces of garbage, then monoliths aren't really designed for humans or our tendencies. That means monoliths are the problem... they don't adapt to human nature.