As someone who works at another company with a big monorepo, briefly:
* Ability to change an API and all its users at the same time.
* Circular dependencies become a non-issue in a lot of cases where the would be if you vendor your dependencies.
* Even if you vendor your dependencies hunting for bugs is a lot easier, your bisect of a bug in a library will just come down the commit that upgraded it from 1.0 to 2.0 without a monorepo, with a monorepo you can bisect anything down to a specific commit.
* Code discoverability / mass edits are a lot easier, and integrate seamlessly into a lot more tools than if you need to manage multiple checkouts etc.
The big thing I miss about Subversion is that you could check out one subtree. On the biggest SVN project I worked on, we built 5 binaries from the same code tree, but only the leads and a couple of senior devs that worked on crosscutting concerns (ie, the people who would do the mass edits you mention) had the entire tree checked out. Everyone else had just the one or two modules they were working on.
The second biggest, we used just enough of a module system to enforce modularity by having a single code repo but separate compilation units. Your circular dependencies between subprojects would show up at compile time (or at least, on a clean build, as our CI machine did). Stopped a lot of obscure runtime issues and made people think about what they were trying to do.
This post is about Mercurial with which i'm not familiar, but in Git you can checkout a subtree since version 1.7[1].
It's commonly called "sparse checkout".
That reduces the history depth, but still gets the whole tree. Arguably, the history is much more interesting than having the entirety of the monorepo for many people.
* Ability to change an API and all its users at the same time.
* Circular dependencies become a non-issue in a lot of cases where the would be if you vendor your dependencies.
* Even if you vendor your dependencies hunting for bugs is a lot easier, your bisect of a bug in a library will just come down the commit that upgraded it from 1.0 to 2.0 without a monorepo, with a monorepo you can bisect anything down to a specific commit.
* Code discoverability / mass edits are a lot easier, and integrate seamlessly into a lot more tools than if you need to manage multiple checkouts etc.