I think the takeaway from your comment is that you really do not understand the sheer scale of volume of changes done by +100k engineers, their heavy reliance on tools that do cluster-based testing (not local dev machine) and the tens of thousands of tools that perform auto-commits.
It’s a lot easier to shit on a big corp. Intellectually lazy, too.
The point is that either product should theoretically have the ability to handle Google's load. They were both built for scale. If I have the timeline correct, they existed at that point. I would expect those organizations to have positively salivated at the possibility of having Google as a customer; they would have bent over backwards to make it support Google's workflows.
The ROI of such a choice vs going custom is the interesting question.
Of course, if I have the timeline wrong, then the discussion is moot.
There is a big difference between one VCS handling 1,000 QPS and 1,000,000 VCS instances each handling 0.001 QPS. A system built for one is not necessarily suitable for the other.
It's not moving the goalpost because you didn't understand where the goalpost was in the first place.
Lots of tiny repos like GitHub? Easy sharding problem. They don't even need Paxos. One large monorepo? Everything changes. Let us not forget that GitHub cannot even handle the Homebrew repo be cloned and updated by Mac users and asked them to switch to a CDN.
It’s a lot easier to shit on a big corp. Intellectually lazy, too.