I think the real sin is just cutting against the grain on your services and library boundaries.

It's not that hard to version and deploy multiple services and libraries. If you need the flexibility of that separation, it can very much be worth it.

But if you separate them and still treat them like you're in a mono whatever and you cut corners on keeping your separation clean and clear, you're going to have a bad time.

Either pattern has its advantages. It's best to remember that they're just a pattern and you should be doing one or the other for a reason.

Oddly, I would say that this often exposes complexity? Not that that is a valid reason to go all in on it. But some things, like updating service contracts, are complicated. Indeed, anything that makes it look like many services all deployed in unison is almost certainly hiding one hell of a failure case.

Having gone from multi-repo to monorepo recently, I'd say the opposite. A multi-repo lets you do those things incrementally. A monorepo forces you to do them in one go.

In my experience, while monorepo makes shared libraries between services easier, that inevitably turns into "Hey, why not just put a copy of my application inside yours?"