What actually happens, 100% of the time in my personal experience, is that you end up with both the old monolith and new microservices, the monolith never gets fully broken up, and now you need to support two development paradigms forever.
Has anyone here ever seen a monolith be successfully 100% broken up into microservices?
It isn't one or the other, the 'skill' is knowing which to apply when.
To make most of these types of projects work, the sponsor needs to demand an incremental approach that delivers real value, piece by piece, all the way up to retiring the original system(s). Tie-out is also necessary for many projects, and all the associated testing. It is a big grind, which is probably why so many of these projects fail.
I'm all for ending old software when the time comes but not everything needs a rewrite to microservices.
Supporting two development paradigms isn't really a thing any reasonably sized organisation should be concerned about.
Especially when you're talking about adding one more build process to hundreds across all your services.
It's not a bad thing, it's actually a quite pragmatic approach. Some folks call it The Citadel:
https://m.signalvnoise.com/the-majestic-monolith-can-become-...
Building monolith is the best way to learn about domain and domain boundaries. Monolith is way more forgiving for your mistakes.
Going all in on microservices is like believing you learned everything there is. Some folks believe that, most of the time they are wrong.