A lot of monorepo strategies that I've seen involve maintaining a DAG of dependencies so that you don't need to run CI over the entire system (which is wasteful if most of the code hasn't changed), but only a specific subset.
Each component within the monorepo will declare which other components it depends on. When a change occurs, the CI system figures out which components have changed, and then runs tests/build/etc for those components and all their dependencies. That way, you don't need to build the world every time, you just rebuild the specific parts that might have changed.
I think that specific concept (maintaining a single "world" repository but only rebuilding the parts that have changed in each iteration) is what the author is talking about here. It doesn't have to be done via a monorepo, but it's a very common feature in larger monorepos and I found the analogy helpful here.
That's a cool thing to have, and I'm glad you found the analogy helpful, but I hope you understand the CI DAG you're talking about is not making anything more stable. It is just to cache build jobs. To make things more stable (what the post is referring to) you need a separate mechanism; in a monorepo w/CI, that's gating the merge on test results (which doesn't require a DAG). (And actually, if you skip tests in a monorepo, you are likely to eventually miss systemic bugs)