Mainframes aren't hotbeds of compute power - they are all about the I/O. Your typical COBOL program reads a record, does some moderate processing, and writes a record out. Over and over. So keeping the input and output channels full so processing wouldn't stall was a key design goal.

As a counterpoint, many very well funded and talent rich organizations have failed to retire what TPF mainframes do every day for airlines, banks, and credit card companies.

Cobol isn't involved, but those slow mainframes are.

To be fair, rewriting huge mission critical systems is hard, no matter of what kind of system it is and what you are changing to.

Non-Blocking i/o isn't really some miracle new-age programming drug. Doesn't change the equation much.

Our mainframe is expensive but it isn't slow. It's not exactly sitting on the same hardware from the 70's.

The amount of performance (particularly CPU) you get per dollar is very low. Mainframes are all about lots of I/O with ridiculously high reliability and availability, but for an absurd amount of money.

Right, but that's our use case and it also happens to run our legacy applications! IBM's support is also very good.

We're not running our modeling engines and that stuff on it. We have HPC for that.

There was never an excuse to not document PHP functionality. Infact, its quite easy to document now, just the same as any other language. Devs simply argue that the 'system is still changing', and so nothing is documented.