Developing software that has been in use for quite a while (like the Maintain network management software I am currently working on), you frequently run into tiny little problems that are somehow the heritage of ancient times. Sometimes, they are easy to use, in other cases they start as small issues and turn into butt-biting monsters ever so quickly.
One of these is MySQL's PASSWORD() hashing function. What was meant to be a good idea - having the RDBMS handle the passwords with its built-in hash - turned out to be a bad one: MySQL's password hash changes virtually with every release (okay I am exaggerating), making your hashes unusable, so your customers stay locked out of your software.
To provide some sort of legacy support, in former versions of Maintain the OLD_PASSWORD() alternative was used to authenticate, followed by a re-hashing of the password with the new PASSWORD() hash.
Still, it's only a matter of months until MySQL decides to change its hashes once again, leading to even more legacy code and less transparency in the authentication codebase. Plus, if people don't want to use MySQL at all, they have a big problem: Most other DB engines don't offer a PASSWORD() function.
Therefore the hash was changed to SHA1, leading to yet another special case in the password validation methods.
Anyway, in the upcoming Maintain 3, old passwords will only be supported through a legacy authentication module designed to re-hash the passwords to SHA1, hopefully one and for all times extinguishing issues with changing hashes in the database backend.
The moral: There is a reason for MySQL to discourage use of PASSWORD() in applications. Believe me. They are right.