It's partly historical: these applications already exist on mainframes, and it would be very expensive to change, so they don't.

But mainframes have a lot of advantages because they are integrated systems designed for exactly the sort of high-throughput tasks that businesses use them for. Their (single-threaded) processing power is good but not outstanding; where they really shine is parallel I/O performance which lets you execute large numbers of operations per second, or distribute workloads across large numbers of processors with extremely high bandwidth inter-processor communication.

They're also designed to be highly reliable, redundant and modular. You can do things like upgrade and replace processors, RAM, and disk drives without interrupting applications. And speaking of processors and RAM, modern mainframes can scale to >100 processors and terabytes of RAM in one system.

Yes, you can build systems with similar specs and capabilities with clusters of commodity hardware, but then you have the complexity of managing a distributed system. With a mainframe, you have a single beefy machine. You'll also have a support contract with the manufacturer to call when things break, so they can be responsible for doing any complicated maintenance.

On the downside, of course, they're expensive in the "Q: how much does it cost? A: how much do you have?" way that enterprise pricing works.

I work for one of the major banks and all the reasons you listed are true. From talking to coworkers who work with the mainframes, the mainframes still provide fantastic performance that Java and other higher level languages haven't matched on the stack (yet). Also, the applications are so large and so critical to our customers that the process of transitioning to a new stack would be a nightmare for almost zero short-term gain.

It should be noted that the industry is trying to make a push for porting the COBOL applications to Java to help resolve issues regarding an aging workforce, hiring, and documentation.

I am not a mainframe guy, but AFAIK mainframes are very special beasts. Especially they guarentee very high aviability and have special hardware features to support this guarentees. So you do not use them in the first place if you are not more scared of downtime, than of hardware costs. And with this comes a specific very conservative style of software development. If it ain't broken, don't fix it. So a lot of the mainframe code is very old and will only be replaced, if the company is replaced by a competitor. And therefor compatible hardware will also stick around until the end of business operations.

As well as the other reasons given here, the cost of conversion is much higher than you might otherwise think. Especially for banks, you have to prove that the new software meets with compliance regulations, not only for the financial regulators but also for the auditors (banking auditing is especially tough).

Compliance does not mean just "meets all the unit tests", but also meets specifications like guaranteed uptime, stringent physical security (that alone could rule out many cloud services), tight audit trails, recoverable failures, incorruptible data, and so on.

It opens up a whole can of worms that will dwarf the development cost of the software conversion alone. It's easy to see why many banks stick with their current working system.