[Also a Googler here, speaking my own interpretation rather than any official policy.]
They make the official policy in-office to set the expectation that that's where you'll be, and then they can negotiate exceptions on a case-by-case basis. I've never seen a high-performing Googler (meaning one who has successfully launched a project) turned down for remote work or office transfers. They don't want the non-performing Googlers (who possibly might outnumber the high-performing ones) working remote though. If you're meeting with engineers as an external partner or customer, it's almost certain those are high-performing engineers, because they wouldn't be put in that position otherwise.
I'd assume that verifying that non-performing Googlers are actually working, and correcting performance issues, is much harder when they're remote. Most knowledge workers pretty much have to be trusted to perform their jobs, but that trust is much harder when you can observe neither process, progress, or results.
In most knowledge work - not just Google - you're fine as long as you're either putting in effort or getting results. After all, software development has plenty of risks, it's possible to fail to deliver for many reasons other than being lazy. But when you are neither putting in effort nor getting results, that's when you're at risk of getting fired, because the company starts to wonder why they're paying you. Remote work makes it much harder to observe the "putting in effort" piece.
It's not just about the code, it's also about the culture.
Non-performing staff could be non-performing for different reasons - not just output - and it's often easier to spot those reasons (and address them) when you're working in the same office.
Source: I've been running a company with hybrid in-office + remote staff for 15 years. Would be happy to expand on the above if asked.
People who consistently deliver code and working features usually don't have a problem getting approved to work remotely. That's the case-by-case part. It's the people whose code is buggy or nonexistent and whose features don't work that are stuck in the office.
But what is there's no code or code that is not used in a working feature? Both ends of the performance spectrum comprise people who don't really code.
I can tell with certainty that slacking in office is extraordinary simple. You can even slack your way to massive overtime, as you chat with this or that person, hang around, procrastinated with actual work or just plain browse reddit.
They make the official policy in-office to set the expectation that that's where you'll be, and then they can negotiate exceptions on a case-by-case basis. I've never seen a high-performing Googler (meaning one who has successfully launched a project) turned down for remote work or office transfers. They don't want the non-performing Googlers (who possibly might outnumber the high-performing ones) working remote though. If you're meeting with engineers as an external partner or customer, it's almost certain those are high-performing engineers, because they wouldn't be put in that position otherwise.