Those COBOL applications will keep working until the sun burns up or inflation makes the numbers so long they no longer fit in bounds.
The java applications they write should fill you with terror.
You will have to eventually relearn regardless what you pick. And I can't believe having some COBOL in the CV will be an issue for anybody.
The developer experience is terrible, it's a completely parallel world that diverged about 25 years ago from what we're used to, and it's not particularly good. Furthermore, it's so obscenely priced that it will be never used for anything new (and forget personal projects), so career-wise it's a dead-end and confines you to only ever work in existing legacy deployments.
The "corporate experience" for the lack of a better word is terrible too. Companies that run this have zero engineering culture (if they did they would've finished their migration off COBOL long ago) and developer positions have about the same amount of respect and political influence as the janitor. There are much better options pretty much anywhere else, so the only remaining people are too mediocre to get those better opportunities, so it's not a good environment to learn from either.
Migrating off COBOL (or any legacy system) is possible - after all, startups have built similar systems from scratch. The problem is that this requires a competent engineering team and you won't get that without a good engineering culture and embracing engineering as one of the key pillars of your business and giving it the resources and respect it deserves.
If nobody can understand the application, it cannot be modified.
If an application cannot be modified, its value will continuously decrease with time.
That decrease in value, as well as the projected cost of building a replacement, is tantamount to accruing interest on a debt.
They could have reduced that debt by moving to functionally equivalent but more commonly taught languages back when their team could still understand the system.
It wasn’t necessarily wrong for them to accrue this debt - after all, banks and these monolithic institutions are masters at effectively utilizing debt. However, the practice may have become habitual and it looks like they might be in pretty deep at this point.
Not having ever seen this kind of software, I would assume that the existing COBOL applications are good simply because all the bad COBOL code was probably scrapped decades ago, an example of survivorship bias.
What you’re describing is a management and leadership failure.
In US tech we have an overabundance of Type A people in it for the money, but there are plenty of smart Type Bs who just want stability and a life, for a fraction of the going SV engineering pay.
You have to wonder why the latter is impossible for American companies to achieve.
But if you already have an old house that's working it's worth considering survivorship bias if you're building a new house to replace it. That new house is much less likely to survive that bias filter. Getting the new house as good as the old house will likely take you far more time and money than you expected.
And the same is with software. For example including outside libraries in your application makes the code much easier to write. You don't have to reproduce functionality. But libraries typically work like kitchen sinks. You may not have wanted a garbage disposal, but your library came with it and for the next X years your application is around you have to make sure that disposal doesn't catch fire. From the security side you have to make sure there is no code interaction with disposal or any of the other 'household' functions its including that you're not testing for.
At least in what I do for a living which is in the field to code security reviews (I don't do these reviews myself, but I work with the teams that do), the amount of security issues that get caught in these new applications in a multi round process, at least to me is staggering. It has to be a multi round process as we see the issues being reintroduced we'd call out in previous sessions. Quite often in these larger organizations the programming teams are so unstable that between our first calls and last calls the entire team working on it will have rotated out.