I mean, this is a gross misunderstanding of how user input makes its way into a database safely. If you're putting out error messages like this it's a giant red flag.
That article is a few years old now and things should have got better, but even by 2016 everyone should have known properly sanitising inputs was critical for a decade or two.
One of the systems is already wrong. The excuse not to do the system right is monetary cost of fixing the broken system.
Out of all the excuses in the world, money wins.
I really don't understand your point. If I hash on the browser the hash is still being sent to the server. A MitM or sniffing attack can just send the hash and log in. It doesn't actually protect the user at all unless they're re-using the password elsewhere. This also assumes that you're using a seeded hash of some sort, or a multi-round hasher with settings unique to every other website. Otherwise you're still going to run into stuffing and collisions.
So for sites where the plaintext password is sensitive (password managers etc) that's important. For most sites, it's not inherently wrong not to hash passwords in the browser, though it does protect against password reuse.
I'm not saying you're wrong, I just don't think you're accurately portraying the problem you're fixing.
(I joke, but 20 years younger me, self-teaching php and security etc? Who knows what she'd think of this)
If a user's password leaves the web application in any form other than a hash, something nonstandard and probably bad is going on.
No, it's unambiguously bad. You're transmitting a cleartext password to a system which doesn't have a business need to know it, and which wasn't designed to process secret data. There's a substantial risk that the database may leak that data in some unexpected way, e.g. by logging it when an error occurs or by showing the parameter in a process list. Worse, a stored procedure can potentially be covertly modified to store or exfiltrate the password while hashing it.
"As early as possible" is interesting. It could be done on the client, however you need to actually have the hash to check if a string hashes to the same as it because of the salts embedded in the strings. Using an algorithm without salting would allow you to hash the password on the client then allow arbitrary 32 (or however long your hash digests are) character strings on the server as a password equivalent. This would also protect from a misconfigured or malicious server logging unhashed passwords.
No, that's actually too early -- if you let the client hash the password, you're vulnerable to a "pass-the-hash" attack where the client submits a hash without knowing the password.
There are protocols like SRP and other PAKEs which allow this to be done securely, but it's uncommon for them to be used in web applications.
In fact, if you rely on client side hashing, you are not only making the app a lot less accessible (it will only work with JS enabled), the security is worse, because now you are publishing a salt to the client. Or you are working with unsalted hashes which is hardly better than just plain text.
SSL is what protects passwords in transit. Not some JavaScript client side hashing DIY.