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.
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.