The point of the system is that engineers operate what they own, that's fundamentally different from SRE. It allows for significantly greater organizational decoupling. At Google, they had to go through an entire ceremony just to get Rust into the monorepo (I actually don't know if they ever ended up doing that outside of the Fuschia repos) while at Amazon someone just created a build script that wraps cargo and now AWS heavily uses Rust for several control plane systems and Firecracker. This kind of agility is not easily possible with an SRE system.
This is really orthogonal to SRE. Google, in many ways, prefers centralized infrastructure. They invest in a few ways of doing things and integrate them all together. Devs have a few tools/libraries/services etc. to pick from and they mostly work together very well.
This makes SRE easier since devs can throw various applications over the wall and SRE only has to learn a few different pieces of infrastructure.
But in practice, any pariticular SRE/dev team pair would work together for a long time and use a small set of infrastructure anyway even if it wasn't the same as the rest of the company. SREs just become a little less interchangeable since other teams will use different sets of infra.
I mean by this logic all tier1 service engineers are just rotating SREs anyway (though I do know some services already have dedicated SREs for operations work)
