It isn't this simple. You have millions of LoC already written, docs, onboarding, hundreds of teams with different opinions, training people in a different tech stack.

In green field development or smaller companies, sure, I however do not find it as exciting since there are not real people / technical challenges most of the time, once you compare with what you can build with 1000s of engineers.

I do not miss Google's monorepo one iota. It had huge benefits, but after stepping back far enough the result also easily begins to look a little like Stockholm syndrome. Anything they want to open source they basically have to rewrite from scratch because of that godawful repo, never mind reasoning about what actually ended up in your binary on any particular day when depending on such a gargantuan tree, and of course not to mention what by now is likely 10s of FTEs dedicated simply to managing the tree.

Those millions of LOC mostly only existed to serve their own purpose, and possibly the intrigue of many a doe-eyed eng. If I came across a codebase like that today, I'd likely be quite vocal on reallocating the evidently outsized engineering budget to some more productive use

Can you expand on "If I came across a codebase like that today, I'd likely be quite vocal on reallocating the evidently outsized engineering budget to some more productive use"

Like, Google (or other company) still has to deliver to production and they do so using their existing system. I believe not supporting the existing system means not having deliveries.

I am actually facing a similar issue in my current job and it isn't an easy thing to move away from.