Password hashing is not for the security of passwords while being transmitted over the wire, but for storage on the server. We hash passwords because it sometimes happens (more often than we would like) that bad people get a peek at the server's files and/or database. For what happens on the wire, we need two things:
We need integrity because authentication is always relative to some subsequently exchanged data. We don't want an attacker, in position to run a MitM attack, to just wait for authentication to happen, and then hijack the live, "authenticated" connection.
We need confidentiality because we do not want attackers to observe passwords in transit, or even hashes of passwords, because a password hash is enough to "test passwords at home". More generally, we usually prefer that the sensitive data we are about to exchange remains confidential (that's not always the case, but it still often happens).
SSL provides both. When using SSL (called HTTPS in a Web context), the connection is protected from alterations, encrypted, and the client is reasonably sure of talking to the right server. Under these conditions, the password can be sent from client to server without any kind of hash applied to it, and that's exactly what happens in most Web sites where you type your login and password. The server must still store, somewhere in its database, some data which allows verification of the password sent by the user; that data element should be the hashed password (with the usual assortment of protections: slow hashing, salts...).