yes, the atomicity argument is the strongest one to me as git submodules are a genuine pain to work with and still don't solve the problem well. Yet a clear transaction around a change affecting multiple components gets even more important as the rate of activity and associated contention rises.

In the ideal setting no, you will have strong contractual boundaries and these will all be tested by integration tests that live in a separate layer - but not on every commit of the sub projects - it will happen less frequently and roll up many changes across multiple subprojects together and test them all at once. Yes you lose some granularity and immediacy but it solves the scaling problem.

Everything works like this in the end at some level. I assume people with monorepos don't retest their project on every Linux kernel commit - it's pointless, you are never going to run against exactly that commit. But you will do it when you do upgrade Linux versions, etc.

There are definitely ways of integration testing and e2e testing dependencies. I think it’s reasonable to wonder why creating a new VCS was chosen as the best solution.

Why would you test dependencies? Test the code that you write. Do not test the code that you did not write. Literally, you should not test dependencies.

I never got caught into the monorepo fad, I'm glad I didn't, and I still don't see a point in having monorepos. Let's say in ruby on rails, I have the host app and 3 mounted gems in it. That's 4 repos. It could be all merged into one monstrosity but separate repos help keep complexity down, and help define interdependencies cleaner and simpler.

The monorepo idea was just a fad. Each package should be its own repo. Each package should be meaningfully useful, e.g. one package for string utils, not one package for trim, one package for pad, etc.