Especially in the financial sector.
Mainframes are weird. They are still used in a lot of places and don't play by sensible rules. People still run these systems with 24x7 operations staff, as in, there is someone sitting in front of the mainframe console at all times.
It is a crazy world out there and a lot of people still use these systems to do terrifyingly important things.
That was, of course, complete bullshit, for a couple of reasons. First, bank customers would not need accounts on the mainframe. A bank customer account would be defined by an entry in a database running on the mainframe, not by a user account on the mainframe. The bank system would essentially be an application running on the mainframe, and bank customers are data for that application.
Second, even if we give them the benefit of the doubt and assume they were really talking about some other kind of password on the mainframe (maybe the database records for each customer are encrypted with a password, and the mainframe's cryptography software can only deal with 8 characters) and so there really is a backend limit of 8 characters, there is no reason that has to imply a limit on the password length for online banking. The web-based front end to the banking system, which is what the online banking customer actually interacts with, can have its own, modern, password system without any such restrictions. There's no reason the 8 character password for the mainframe has to come directly from the user--it can be derived from the front end password.
I did some work in COBOL on a Unisys mainframe back in the late 90s, and I'm still impressed by that thing. You could walk over, pull the plug on it while it was in the middle of running a payroll job, a finance job, and half a dozen other things. Plug it back in, wait a few minutes, and it would pick up right where it left off. No data corruption, no other hassles.
Migrating away from that thing was often discussed, but it would have been a tremendous hassle. For one, there was no simple way to migrate the huge volumes of data off of it; for another, even if you could, decoding it would have been a neat challenge. Then there was the matter of all the years of business logic that, while not pretty, worked with very few problems.
...and this was just for a school district in the East Bay. I can't imagine what it would look like for a big financial company.
Once you rely on a mainframe the cost of continuing to operate it, while fairly large, is hilariously less expensive than moving all that code and data elsewhere. Especially given you will have to test all the code again and most people don't even know what it all does anymore, much less how to make sure it's doing it correctly.
The same system does in-flight encryption (client communication to server) using a trivial byte-based XOR cypher, with the offset communicated in the clear when the connection is established.
There are big problems out there.