You are describing the consequences of poor architecture and process, not anything intrinsic to software projects.
Right, and our empirical observations over these topics are different.
I just read your profile and frankly the projects/industries that we are involved in are very different, only confirmed by throwing "C++" out there - the closest I get to that is some hobbyist C development.
I apologize for agreeing with parent comment's generalization at 100k LOC being a "mega-monolith", along with what I added with team sizes/decades for timelines. Empirically and anecdotally this is what I personally have observed, specifically in regulated fields ie: banking, payments, and education. This is a perfect example as-to what happens when I don't include the word "anecdotal" in my HN comments...
Developers from different industry niches have very different ideals in regards to what a "monolith" is, or what a "two-pizza" team is capable of over time. I find your "wait what?" comment to be a bit dismissive, only to end your comment directly telling me what I am describing which clearly implies I don't know what I'm talking about.
We likely just have different experiences with project complexities, sizes, teams, etc. Sorry if this comes off as aggressive.
Huge teams and decades of time gets you to 1M+ range, not the 100K+ range.
I feel weird defending myself but... yeah. This is actually my experience.
I get that teams at FAANGs/startups can typically move faster but for your run-of-the-mill corporate America development teams people do not move that fast.
Personally, I have only moved that fast at startups which is why I typically find myself at them.
Again, this is anecdotal to my personal experience.
You don't get to that LOC count without huge teams and decades of time. Any project of that timeline/complexity/size should constantly be having functionality split off so that organizational units can be better groked/understood. To put it a different way, when projects hit this sorta size I have experienced them naturally shedding off functionality that makes sense to be external in a service-based development strategy.
These are the situations where it 100% makes sense for microservice architecture as you've hit the social/technical complexities where breaking things into organizational units makes sense.