I don't have a ton of experience with any of them, but I've had a few run-ins with COBOL. Most notably, at my last job I was working in a team that was actively working to replace a large legacy COBOL system for retail supply chain management. I never worked with the COBOL applications directly, but the stakeholders on my projects overlapped with users of that system. Less personally, but with more data points, there's a large employer in my city with a substantial code base in COBOL who actively recruit career changers and teach them COBOL. I've met several people who went that route while doing outreach and trying to mentor new developers in my community.

My general impression is that the large COBOL codebases are used across a lot of different parts of industry, and for a lot of different things. The most common feature is that COBOL applications continue to be used in organizations that are so dysfunctional and bureaucratic that they can't successfully agree on how to replace it. The general shape of the problem seems to be that business decisions were made decades ago, and written into the codebase. Replacing the codebase would mean that someone at some level would need to sign off on requirements, which would mean taking responsibility for something, and the organizations that can't move off COBOL are so toxicly risk averse that nobody will make an affirmative statement about any requirement. Instead, they manage to just barely get by with a combination of very experienced developers who can retire comfortably and DGAF and make decisions, and very junior (and poorly paid) developers too naive to push back or ask too many questions.