When we build a monolith, assuming we use best practices like strong interfaces and separation of concerns - our monolith will be a "modulith". It sounds a bit funny to me: if we won't "cheat" and apply best practices, the level of complexity of the code will remain manageable and it will remove the strongest reason for MSA.

The problem is the we're humans, we're sloppy, we have deadlines and sometimes we'll take "shortcuts", which will break our beautiful strong interfaces and SoC...

When we do it once or twice, nothing bad happens, but if we'll keep doing it (and over time we will!) then the monolith will become the "monster" you described.

By using MSA we force developers to maintain clean interface and SoC simply bc they have to... They'll need to call a different service for a different concern and there's no shortcut they can take even if they'd really like to.

And that is, in my opinion, the main reason for the popularity of MSA: it forced engineers to keep it simple which reduces complexity and which, in return, increases velocity.

But nothing is free, and as you mentioned there's some maintenance around it that requires extra work.

That's a trade-off and if the company is a small startup with 3 engineers they probably won't have the bandwidth for it and will (wisely) choose a monolith (with an aspiration to keep it a "modulith"), but if the organization is more mature and has resources, it probably will be better off with MSA.

Plus, remember Conway's law :)