It works for some kind of projects and i was motiviated for this talk, because I saw so many projects using manyrepos in cases where it may not fit very well.
A few points got me concerned in the slides - namely, concerning emphasizing how easy this makes to change things. I would consider that it is not a positive thing that adding a library is cheap and easy, and I find that component versioning can be bypassed even more so.
It all sounds like grievous local greedy optimization without a view of the entire lifecycle of the codebase. The slides say change is the only constant. I would claim that unless the change is backed by good and strong architecture - which throwing all architectural firewalls away does not support - then the end result will be a mess of spaghetti the older the codebase gets.
But, I may just be too much set in my ways of coding and I respect the fact that these may be non-issues in the particular domain these slides address.
I think build systems and internal code management schemes are large interconnected systems. It feels fairly pointless just to expose one facet of the entire systems since the total system encompasses all of the individual entities dealing with the codebase - including developers, platform - the whole works.
For example, I see no overhead in my daily work from the fact that our codebase is split to several libraries with dependencies through explicit built release versions. On the contrary,there monorepository would be just horrible.
So, before saying X is great one should firsr define what type of software is built, what is the specific toolchain, what are the specific configurations, how many developers modify the same codebase frequently, and so on.