If there exists appropriate tooling (e.g. for filtering commit logs based on what touched the code belonging to a single project / what touched the code belonging to a single project and its transitive dependencies) then I dare say a huge monorepo history over many projects and libraries isn't polluted history, it is remarkably rich and useful history.

In big places with solid engineering teams and a long-term investment in infrastructure it seems achievable to build the tools to do this properly. (famously: google, which isn't a very fair example).

I think many people's default reaction to monorepos -- fear, loathing and disbelief, say -- is based upon working with open source tools / related cloud services / distributed workflows - that scale poorly when dealing with large repositories, at least with default configuration and without a lot of mucking about.

That said, this default reaction is arguably a healthy reaction if the reality is that most teams / organisations do not have the resources to invest in setting up tooling / infrastructure beyond what they can get for free / rent for a few hundred dollars a month.