Maybe that is the right decision. But Google has organically grown over the decades and their tooling evolved with that.
It's hard to say which requirements they were working with and what they were trying to optimize for - sometimes higher costs are just okay if they allow or enable other things.
For me it's always "what are we trading?". In an organization the size of Google, it's far easier to amortize away the cost of such a thing. That doesn't mean it's not a cost, though. And there's a lot of tooling around modern SCM that they won't get because they're on a bespoke system, so there's a cost there too.
As you say, at the time the variables may have been very different.
It's just an area where if I had to make that decision (even back then), someone would have had to be exceptionally persuasive to convince me to authorize what is effectively a multi-million dollar project... to recreate source control. =)
I wondered if it would have been cheaper overall to use pre-existing tools and adjust things than to build a whole new product that has nothing to do with your core business, and then have to maintain that product. This is a wholly different argument.
TANSTAAFL right back at you; development and maintenance time is not free either, and there's a potential argument that pivoting their other tooling would also open them up to other off-the-shelf opportunities, though that is much harder to evaluate.
I've worked at scale. I am well aware that sometimes custom is the only way. I've been there and done that, and walked it back when someone finally did something off the shelf that was cheaper to maintain. Custom comes with a cost, and that cost can often be hefty.
Source control... is not usually where you hear the "it should be custom" argument, and even less often is it at all supportable when you look at the big picture.
Google is certainly large enough to have unique requirements, but that alone doesn't justify the choice.
I thought about the larger organizations, and of them I could identify only Microsoft and IBM as other companies who have their own SCM products (though that's probably ignorance; there are probably more ;). The difference with them, though, is in the fact that they sell those products as products, making them part of the core business. Profit center instead of cost center.
Google doesn't do that AFAICT, so all that investment in development and maintenance is nothing more than cost at the bottom line. And not just monetary cost: what else could those developers be doing with their time?
Hence, it really makes me wonder if there's a bunch of developer religion that's costing Google a lot of unnecessary cash. If I were by some strange miracle brought in as a CTO at Google? I'd be wanting some pretty hard facts on that (or a plan to productize it) to justify its continued existence.
If someone tells me that monorepo (or multirepo) is better, I'll respect their opinion even if I disagree with it. If, however, someone tells me that one or the other is the only way, and they must have a custom source control system to prevent things from collapsing like a house of cards?
Yeah, I'm going to call bullshit.