If it's been developed as a singleton application (all features always registered/enabled on startup, only one instance ever running), even that might prove to be quite hard. No idea what else to call a monolith that could never run as more than one instance at the same time.

You might have to go through dozens of files and sprinkle feature flags throughout to enable/disable certain modules and making any organizational changes to a codebase over a million lines of code is difficult. Plus, when you have 1000 API endpoints that's generally treated as just "the API", then splitting that up in meaningful ways might present challenges. Aside from that, even if you can cut down on what needs to be enabled for certain development scenarios, you are still compiling the whole monolith, so locally you're saving on some runtime resource usage at best and will still sit around when you make any changes that need you to relaunch the monolith.

In general, I agree. I'd even build new systems as modular monoliths first. Except when it comes to large systems of any kind, even just updating the dependencies might sometimes be impossible (in a reasonable timeframe).