If the system works, and is fast and efficient enough for the task (which is clearly is), and supports the needed features (there was an article on the things you could do in COBOL a while back that went over this), then what is the benefit?
Sure maintaining something is not as "fun" as writing a new thing, but that doesn't make it better.
Anyway, the "obscure mainframes" isn't true - yes there are cases where the easy path was simulate to emulate a PDP on modern hardware - but there are, for example, COBOL implementations the target .net, in addition to regular unix and windows targeting compilers.
Edit: and I forgot my original reason for replying: the use case for mainframe software is drastically different from consumers.
The big scary mainframe software is generally designed to be essentially a few users, running on a restricted set of homogenous hardware and system software. They are generally specialized so that's all they have to do.
Consumer software is not as forgiving - generally a user expects software they bought 20 years to still work, and likewise will assume that their 10 year old machine should still be able to run new software "because it still works". Look at the commentary on Apple deprecating 32bit software. Or the complaints about Windows N breaking legacy software, while also laughing about the things MS does to keep old things running.
Problem is that you are locking yourself. Even if this work for decades it can destroy your company. At some point, you will not be able to respond to change. More agile, faster-moving competitors will eat your lunch.
I am not suggesting rewriting to use new shiny things. If the platform is deprecated (32bit, mainframes, windows98, C89, etc) you migrate your code when it is still possible. Customers can still use an older version of your software is they are stuck in the past but you are not compromising future of your product.
High-risk complete replacements happen because some risk-averse developers/management resisted change for decades and now the company cannot gradually modernize.
In fact, Google has been actively trying to migrate their code base to C++17 compatible status for several years. It just took much more time than the initial estimation.
If the system works, and is fast and efficient enough for the task (which is clearly is), and supports the needed features (there was an article on the things you could do in COBOL a while back that went over this), then what is the benefit?
Sure maintaining something is not as "fun" as writing a new thing, but that doesn't make it better.
Anyway, the "obscure mainframes" isn't true - yes there are cases where the easy path was simulate to emulate a PDP on modern hardware - but there are, for example, COBOL implementations the target .net, in addition to regular unix and windows targeting compilers.
Edit: and I forgot my original reason for replying: the use case for mainframe software is drastically different from consumers.
The big scary mainframe software is generally designed to be essentially a few users, running on a restricted set of homogenous hardware and system software. They are generally specialized so that's all they have to do.
Consumer software is not as forgiving - generally a user expects software they bought 20 years to still work, and likewise will assume that their 10 year old machine should still be able to run new software "because it still works". Look at the commentary on Apple deprecating 32bit software. Or the complaints about Windows N breaking legacy software, while also laughing about the things MS does to keep old things running.