I only have minor experience with COBOL, but in my mind the issue is that those 800 million lines of code don't have a single unit test, because testing COBOL is really hard. Which makes it dangerous to do any refactoring.
Specifically the snippets I've seen do some in-line SQL to get its data, some business logic and then updates. The logic is rarely in a procedure that takes parameters, because that doubles the number of lines of code you need. So the only way to test it is to bring up a database, insert some test data, assert and clean up the database again. Which is a lot harder since "insert some test data" gets complicated because of different constraints and triggers etc. Then running it regularly is harder than it should, there's no SQLite equivalent database so you typically need to run it on a mainframe etc.
I've worked on replacing a piece of functionality from COBOL to Java, and I was working from the business requirements that was basically a large spreadsheet of conditions and results. E.g. if age > 67 and not retired but have more than 3 kids, etc then this value. The code I wrote was gnarly because of all the combinations of different conditions, nested ifs 3-4 layers etc. And then there was ambiguity if multiple conditions hit, which one took precedence. I asked if I could look at the equivalent COBOL and the actual logic was about 10 lines long (not including headers, comments etc). Wish I had seen that before I started coding. It was quite readable and well commented too.
So the actual language isn't _bad_, but the lack of tooling around it is severely lacking.