First, when you're talking about encrypting passwords, then sending them to the server, that implies to me that you are storing the password in plain text, which is a very bad idea (if you are encrypting them in the database, it is slightly better, but still not ideal, since the key would still be stored on the server somewhere in plain text).
No, you're quite incorrect. PHP's encryption function resides on the server itself. He's not storing the passwords as unencrypted text, however, he is sending it unencrypted via the wire (from the browser to the server). His best bet is to get SSL encryption on the domain itself (https://) so everytime he logs in, the request (and corresponding response) is hashed using the latest algorithms.
I think there is a bit of confusion with our definitions. When I'm saying encryption, I'm meaning applying a key to some plain text to encrypt it, so that it can be decrypted at a later date (such as AES, RSA, HTTPS, etc). By hashing, I mean applying an algorithm on some plain text to encrypt it, so that it cannot be decrypted later, by anyone (such as MD5, SHA-1, SHA-256, etc; not HTTPS).
He was talking about two different things: encryption between the client and the server and encrypting/hashing the passwords in the database. You're correct that the PHP/MySQL functions will handle the encryption/hashing of the passwords in the database, but they will do nothing for encrypting the communication between the client and the server (he'll need HTTPS).
Second, PHP code is not executed on the client's machine, so even if you did encrypt the password with PHP, it would still be sent to you in plain text, which is bad.
This is vague. When the client causes a POST in a form, the password is sent to the server unhashed. All HTTP traffic is insecure, if you want to secure traffic then use HTTPS (but you need to purchase an SSL license). This way, even if the user enters his password, the browser encrypts the request and sends it to the server encrypted.
That's correct (he could use a self-signed certificate for free, but that is not as secure as one from a certificate authority - i.e. if you can afford one, buy it).
That's one way of doing it. Sending it via an HTTPS session secures the unencrypted password over the wire by encrypted the request in itself.
On further thought, I don't think the first hash is necessary (the one done on the client's machine), because if they can get that hash, they can get access to the account, and if they have your password, they can determine the hash.