That's just thing. I think there's this view/assumption that they're all in their 70s, and in some shops that may be the case; but this is an active system actively managed and enhanced/developed. These are normally aged developers :-)
(Heck, I did about 18 months of "some COBOL" along other stuff for a job right out of university. It's... fine? It's a language:)
Is it hard to recruit younger devs? Also, I heard that the hard part of using Cobol is that almost every one uses a different "flavor" of Cobol, with different tool chains and most of the ecosystem is proprietary. Is that still true?
It's true, but way less true than for any other modern programming language I've seen today with our fancy frameworks and models and libraries and methodologies changing radically every 12 minutes :).
That being said, the hard part of COBOL is not COBOL, or even tools/framework. Hard part of COBOL is that it's primarily a business language, as per name. If you're coding in COBOL, you're unlikely to be developing a new webserver or compiler or webpage or whatnot. You are unlikely to be focusing on technology and agnostic to the business domain it's supporting: In fact, you're coding key critical business logic, so you really need to be 30% good at COBOL, and 70% good at understanding business, talking business requirements, and eliciting business requirements from extremely non-programing people.
Again, cannot speak for the full COBOL ecosystem, but I have never recruited a "COBOL person for just COBOL" (other shops I'm sure have). It's something that sneaks up on you - maybe it's one of 3-4 things you need to work on a new job, or maybe there's an emergency legislative change and James is on vacation so Fatima looks at the COBOL program and changes a simple tax formula on it, and bam, now Fatima is the local COBOL guru and gets more and more COBOL assignments until she is de facto actual COBOL expert :).
More specifically, I have worked over my career on a lot of PeopleSoft systems - ERP applications for Payroll, Finance, CRM, EPM, etc. Almost all languages in it are if not proprietary, than weird and unknown to HN audience: PeopleSoft and PeopleCode application engine, SQR (Structured Query Reports) and COBOL. The application itself is made in standard languages, but updating and customizing the business logic for decades of ownership is primarily in those 4 languages. So you don't become a COBOL developer, you become a PeopleSoft developer and COBOL is one of the pillars of it. Thus, I don't hire COBOL developers, I hire PeopleSoft developers.
(Heck, I did about 18 months of "some COBOL" along other stuff for a job right out of university. It's... fine? It's a language:)