Let's say we have a Server with a private and public key, the latter available to all Clients and we have a Client who doesn't have any asymmetrical keys of his own. We want to establish secure communication between the Server and the Client and the Client has to ensure Server's authenticity. This is a pretty common situation.
Now, it is my understanding that private/public key pair is usually used in such situations only to ensure authenticity (our Client can use the Server's public key to verify the Server's authenticity). To ensure two-sided communication between the Server and the Client Diffie–Hellman key exchange is used and the communication is then based on a shared secret key.
I can't stop by wonder why Diffie-Hellman is used at all in such situations. From what I understand Public-Key Cryptography could be used to both ensure authenticity AND to share a secret key between the Client and the Server. Server can send to Client a message encoded with its private key and Client can decode it using Server's public key to confirm its identity. Furthermore Client could use the Server's public key to send a new random secret key to the Server. Only Server would know this secret key as only Server knows his private key. I know some people advice not to use a public key to both encode and decode but nobody says why.
Obviously if both Client and Server had their own public/private keys they wouldn't even need to share any secret keys, but that's not a typical situation.
So... to sum it up. Why is Diffie-Hellman used instead of Secret Key Distribution with a Public-Key Cryptography? Any advantages?
I can't stop by wonder why Diffie-Hellman is used at all in such situations. From what I understand Public-Key Cryptography could be used to both ensure authenticity AND to share a secret key between the Client and the Server.
Both Diffie-Hellman and RSA key exchange (where RSA is used for encryption) can be used with SSL/TLS. This depends on the cipher suite.
Server can send to Client a message encoded with its private key and Client can decode it using Server's public key to confirm its identity.
This is indeed what happens with DH key exchange with RSA or DSS authentication: the server signs its DH parameters using its private key, and the client can verify the signature.
Furthermore Client could use the Server's public key to send a new random secret key to the Server. Only Server would know this secret key as only Server knows his private key.
This is more or less what happens with RSA key exchange: the client encrypts the pre-master secret, which only the server can decipher.
You can read about all this in the Authentication and Key Exchange section of the TLS specification (leaving aside the anonymous key exchange). The choice of cipher suites (See Appendix A.5 and C), which depends on how the client and the server have been configured, will determine the key exchange mechanism used.
Fixed DH exchange is rather rare as far as I know. Ephemeral DH (DHE cipher suites) is more common. It can provider "Perfect Forward Secrecy": even if attackers get hold of the private key, they can't decipher existing traffic, since they would also need to have the DH parameters, which are not the same for all connections. However, this has a cost in terms of performance. You can find more on this topic in this article.