Figuring out the requirements is a research project unto itself. The churn of people over the years means there is no single source of truth for what the system does or why. I wrote an answer about this at https://softwareengineering.stackexchange.com/questions/4252...
You generally want to improve on what you have in some way (or else why do it?), but the line between the warts and requirements is blurry.
Incremental replacement is often a hard sell on the relationship side of things because the customer is seeing a reduction in functionality until everything is done. You can mitigate it and work around it, but it tends to excite waterfall urges which drives up risk.
You also have the fact that the organization keeps changing, so your target is also changing.
There is also an opportunity cost to the whole venture. All that time you spent rebuilding what you had could have been put into new ventures or back into core business.
If you look into modernization type efforts, you see a lot of failure and a lot of loss. That isn't to say it's impossible or that it isn't ever the right answer, but it definitely isn't safe or easy.
Also, sunk cost fallacy. Any reasonably complex COBOL application has lots of lines of code, which are easily counted and in some cases may have even been originally paid for per-line on expensive contracts still on file. That gives a lot of "weight" to that sunk cost on the books, even in timelines of half-centuries. "You want to rewrite a hundred thousand lines of once very expensive code?" you can hear the ghosts of bean counters past shouting in the corridors no matter how much you explain to them that they should have better amortized and depreciated those costs decades ago.
Rewriting software is a massive slog and is prone to all kinds of subtle, possibly very expensive bugs. Especially when the original software has no tests to verify expected behavior in edge cases.
If you hired and trained competent people to do the rewrite, sure. A lot of places will just outsource to a cheap offshore team and be surprised when nothing works.