Well, I gave a specific example in Rails, using DB migrations against a shared DB. It’s not an unsolvable problem, and of course each dev can have their own DB, but if this is poorly managed it’s easy to become unwieldy. Outside of that, if many devs are constantly making dependency changes such that every time you “git pull” you have to rebuild environments, etc. Maybe devs are adding features but not prepopulating dev environments with sensible test data so your dev environment gets horked. Etc etc. Its not usually about merging the code itself.
I'm curious what their data access layer looks like underneath that monolith. Is the Rails piece mostly now just a frontend for dozens of other services, properly owned and maintained by other teams? I don't mean to trivialize something that's obviously huge and complex as "just a frontend", but IME one of the biggest things that breaks down in a Rails monolith as it scales is heavy, direct usage of ActiveRecord. Either there's lots of DB migrations happening since there's so many different developers working on different features, which makes development with a shared DB tricky, or the scale makes DB performance problems hard to diagnose since they cut across many teams or tables in complicated ways.