I agree with you somewhat there; you mean refactor instead of rewrite and yes, I believe that is a better choice. But the problem is not language related; Joel Spolsky said it with far smaller and more modern codebases, but, as you even indicate within #3, 100000s of changes were done in the code over 30 years by people who did not understand the full system or, often, did not even understand the local parts they are editing fully. A lot of changes in legacy code, but let's not kid ourselves, also in modern code, depend on 'things' the programmer deemed right at that moment. Then after testing (even testing in practice with people's money), now after unittests (or in practice, with people's money), too much of the business logic/functionality depends on bad code. Code that is off-by-one that isn't discovered for decades or at all is not unheard of for instance because that routine is only triggered for a specific insurance policy only 100 people have and for those 100 the bug actually gives back the right answer. It would require deep understanding of all the corner cases and that's why it's often just not rewritten.
We were working, around 2000, on partially porting a Cobol+Fortran insurance system (which was an 'integration' of systems acquired by acquisition over the years) to Java (yes, EJBs..... ..... ..... the sins of my youth...). The work was mostly 20 people working for months on creating all the encoded rules into spreadsheets and, in a much shorter time, us translating those to Java. This particular piece was done because the company wanted to webify that part of the system. I am not sure if the modern versions of 'software mainframes' or modern hardware mainframes would be fast enough to handle web with the old code running?