With one-or-two exceptions, what the paper describes is very familiar and sounds like most software teams, but most teams don't achieve Google-like performance/stability/success.

The differentiation is in details that the paper doesn't explore.

I agree, this paper will just lead to more monolithic Git repos "because it's good enough for Google", without the appreciation of Google's other tooling and processes.