Of course leaking the hash of my password might make it easier to crack, to some extent, but if they've done a good job then this is much better than it being something the bank can trivially lose.
Putting aside the banks who literally do store the password because they have security procedures like "Please enter the first and fifth characters of your password" even those that do store a password hash still need you to submit your password to authenticate.
So, like the lyric says, you tell the bank your password. You hope they just use it to authenticate you and immediately discard it, but if bank security lapses are anything to go by they're probably logging it "for security" and there are definitely employees able to snoop the decrypted plaintext passwords from customers on some internal teams.
That is what Augmented PAKEs fix, it's really hard to do well, and of course banks see themselves as infinitely trustworthy so why would they bother.
This mistaken sense of self-worth applies to your credit card PIN by the way also, of course banks and thus bank employees can know your PIN, which means when a purchase is "secured" by the PIN that rules out some local pickpocket having made the purchase, but as well as you it leaves open the possibility that it was a bank employee or their co-conspirator.
Any bank that restricts which characters one can include in a password probably doesn't store a hash of it.
"#" can mean phone number "+" or "&" can mean concatenate variables
It is vastly easier to screen out possible problems at the user/browser level than rewrite zillions of lines of legacy code.
Even with Client side hashing, the software can still validate password requirements on the client side, you may be able to bypass those requirements by modifying the client side software.
So still no, having password requirements tells you nothing about whether the password is being stored in the clear or not. The statement that I disagreed with is still completely false.