I agree, but a further point is that not all consumers need to or care about upgrading. I worked on a project before that used an 8 year old version of an in-house dependency. It worked perfectly for us, and out use case did not jam up or limit the team that owned that library. It morphed into something completely different after years of development, and the library team would have been hamstrung if they could not have innovated the ways they did on account of needing every merged commit of the code to continue to support our old legacy use case.

You could think of it in terms of Python 3 and Python 2 for example. Imagine if Python was an in-house library at Bank of America. Tons of teams there still happily use Python 2, and plan to keep on using it for a while even after official support is deprecated from libraries, etc.

If it lived in a monorepo with this deployment policy (that everything had to be in sync on every merged commit), then you could never attain implementation of Python 3.

The same idea plays out at all sorts of scales. It’s not even necessarily part of monorepo tools, it just happens to be a misguided way that a lot of organizations set up their monorepos.