C++ these days is a far more pleasant beast than the VS6 days, the tooling is pretty good and the language can be tamed into a pretty elegant beast with the right coding standards and discipline.
It only takes a handful of extremely passionate engineers (and I really mean a handful, like less that 2% of engineers in an org) to raise the quality-floor of the entire codebase.
It only takes a handful of extremely passionate engineers > It only takes a handful of paid engineers, full time assigned to the task
What I mean to say is that with a monorepo, you leave the door open to essentially passion-driven contributions made by the other half of that 2%. In non-monorepo environments, the barrier to uniform adoption is too high for someone that isn't full-time assigned to the task to justify.
Some people are genuinely passionate about this stuff, and want to take on the task of migrating the entire code base, because it's a fun challenge and it'll improve their day-to-day work every day for the remainder of their employment. They're very rare, but they do exist, and with a monorepo those people are better-equipped to drag the company forward.
As a hobby thing I'm taking an almost 30 year code base written in C and reworking it into C++17. I've become somehow somewhat adept at this transformation over the years :-)