The monorepo seems like a bit of a red herring. A fork maintained in a separate repository (like pressing the fork button GitHub) would achieve the same. In fact, the type aliasing feature was added because Google (and others) struggled to make modifications in single commit, so the atomicity the monorepo could theoretically provide has already proven to not be there in practice.

The main difference is that Google is comfortable with having a fork that they can update from the mainline branch when needed/desired, but will otherwise stay stable for their software. Others, who are familiar with more traditional package tools, are not. And perhaps their concern is justified, but interestingly I've never seen a Go experience report reporting why that approach failed them.