TBH, I'm not convinced that a great effort to think about "how to stage changes that span many repos" is always (or maybe even often) a benefit. It seems like the simpler approach of just making it easy to make multimodule changes is a benefit of the monorepo.
Having to stage changes across multiple repos, and minimize dependencies between them, can definitely create more work up front. The point is that it lessens the recurring cost (not just across time but across many developers) of having those spurious dependencies in the code forever. Code spends more time being maintained than being written, so it's the recurring cost that dominates long-term productivity.
That depends on your deployment model. Google is live at head, with no support for past releases. In the web world this is reasonable: they control the servers and thus can force releases. I don't work in that world though, there are times where I have to support customers on older releases who refuse to upgrade (when the customer is spending millions of dollars per year you can't ignore their rules no matter who stupid you think they are). Thus I need to think about those factors anyway.
Google still has the notion of release branches. They're point-in-time snapshots of the monorepo (copy on write), plus the occasional cherry-pick from HEAD.
Development happens at HEAD is the important part.