Why different key exhange techniques for ssl key exchange?

I think you misunderstood what you read, or you got some bad information. Your premise is not accurate. You said "sending the symmetric key to the server encrypted with the server's public key" is outdated. That is not accurate. There's nothing wrong with this way of doing key exchange. In fact, most SSL sessions that are negotiated today use exactly this technique. There's nothing outdated or problematic with it. You also said "Now for key exchange Diffie Hellman and other techniques are used." If you meant that Diffie-Hellman has replaced the traditional method of encrypting the symmetric key under the server's public key, then this is not accurate either. Diffie-Hellman has not replaced those methods. The Diffie-Hellman approach is fine and valid too, but it is not accurate to say that Diffie-Hellman is somehow newer (in fact, it is older) or that it has replaced other methods.

I would imagine at the core of it, if it is not put on the wire, it cannot be sniffed, and is harder to break. I can imagine a scenario like this: An attacker somehow gets in the middle of the communication between the server and clients, and logs all data. After awhile, the attacker is able to compromise the server's certificate, obtaining its private key. With that, all captured SSL sessions can be compromised, since the shared secret can then be decrypted. Diffie-Hellman prevents this, with each party having a secret, and another bit of data relating to that secret that is considered public. Once one party has received the public piece of the other party, a bit of fancy math is done that generates a number that is related to both secrets, but is not obtainable from the public information. So, in short, the DH key exchange can be sniffed, but the shared secret cannot be obtained. In the above scenario, unless the attacker compromises the server itself, and installs a modified version of the SSL suite that logs the shared secrets (a much trickier task. Getting the full certificate may just involve social engineering, or compromising another box), the captured SSL sessions are still safe, since the shared secret is never put on the wire on any form.