Considering Google has teams designing custom PCBs and even ICs, there's a non-insignificant amount of Google devs who could easily circumvent this entire system.
The purpose of ascertaining device identity is to prevent someone who can't obtain legitimate Google issued hardware from using stolen user credentials. If you're already a Google employee you can just ask for more trusted hardware, so there would be little point in breaking that part of the security model.
Well, there was recently a case where one of the developers for Google's custom LIDAR hardware stole the plans and gave them to Uber.
And people argued he had no option to hide it.
As I mentioned there, too, it's trivial to break that security if you have the knowledge to design and reverse custom ICs, and you could just steal the laptop of someone else, clone their trusted hardware system, and ensure their laptop is back in place.
Then later use that account to download the data to be sent to Uber.
I mean, for many cases of corporate espionage this is easily doable — it's just fancy DRM, after all. Not by the average dev, but for people who design this hardware or similar hardware in the first place, definitely.
Google's model requires two factor user auth, and trusted hardware.
Even someone with serious hardware-foo would only be able to maybe break the trusted hardware bit (by cloning one device id to another, or emulating a device). They couldn't get round the two factor authentication bit.
Like many things, I'm sure you can make a case for exceptions or whitelists --although granted they likely monitor and or shunt traffic to less trusted vlans or something?
The ultimate BeyondCorp setup has no vlans. All networking kit is considered untrusted (and can be the public internet). All traffic is end to end encrypted between the employees device and the specific server they want to communicate with via HTTPS.
Obviously, getting entirely to that model is a lot of work, mostly for services which don't use HTTPS (network shares, ftp, smtp, ssh, enterprise java apps, etc.)