These should be as basic as not storing cleartext passwords.
Most newly CS students would know better then to do this or at least would know they have to properly look this up.
It's sometimes hard to believe major stupid things like this are done accidentally. (But I know very well how they happen accidentally, it starts with some bug somewhere with non-us-ASCII/to long and similar, then it's constrained "temporary" and put on a must fix list but that list never gets any priority ever, things like this are sadly supper common. As long as companies don't get legally hold responsible for negligence this won't ever go away.)
But the password complexity, rate limiting and other security measurements are there for a reason, and whoever cannot learn from history are doomed to repeat it.
You would think that "not storing cleartext passwords" is a universal given today, but the corporate structure controlling software design today actively suppress anything that isn't a feature. It silos security responsibility to the point where nobody was probably in charge of making sure there was a coherent password policy, that it conformed to any type of standard, or that it was enforced in production against their multiple running systems.
This is every company today.
One thing that causes them to be prioritized where I work is that if they come up during a yearly review, you can't ship your app. Overriding that "stop-ship" order requires C-level approval. Because without a specific exploit, it might be hard to convince a PM to move those up in the backlog.