By storing a staled hash of the password and then using this same hash as an authentication token, an application is more vulnerable to attack because this application is now storing authentication credentials in plain-text. An attacker can use SQL Injection to read this hash and then authenticate without having to crack the hash to obtain the plaintext password.
The OWASP wiki entry refereed in this question was misleading and was removed:
Here is how the salted MD5 technique works: the database stores a MD5
hash of the password. (MD5 hash is a cryptographic technique in which
the actual value can never be recovered.) When a client requests for
the login page, the server generates a random number, the salt, and
client computes the MD5 hash of the password entered by the user. It
then concatenates the salt to the hash and re-computes the MD5 hash.
This result is then sent to the server. The server picks the hash of
the password from its database, concatenates the salt and computes the
MD5 hash. If the user entered the correct password these two hashes
should match. The server compares the two and if they match, the user
MD5 is not appropriate for passwords. This is a broken primitive and a violation of CWE-916. Even if this was describing a secure challenge response, HTTPS is a more appropriate tool and is required to protect the session id.