... when the client could just create a random symmetric key and encrypt it using the servers asymmetric public key?
Quello che stai descrivendo è essenzialmente lo scambio di chiavi RSA che è anche disponibile, almeno fino a TLS 1.2. Il problema è che questo tipo di scambio di chiavi non fornisce alcuna segretezza, cioè se l'attaccante riesce a ottenere la chiave privata del server, può estrarre la chiave simmetrica dallo scambio di chiavi a questo server e quindi decifrare qualsiasi traffico precedentemente sniffato a questo server. Contrariamente a questo DH risulta in una chiave che non è associata alla chiave del server o altri segreti statici e quindi fornisce la segretezza in avanti.
Anche se l'attaccante ha accesso alla chiave privata e vuole solo annusare la connessione corrente, la DH lo rende più difficile. Con lo scambio di chiavi DH l'attaccante deve trovarsi nel mezzo, cioè deve creare una connessione TLS tra client e attaccante e un'altra tra attaccante e server, usando entrambi lo stesso certificato e la chiave privata in modo che la vittima non se ne accorga. A seconda della posizione dell'attaccante nella rete, questo attacco attivo può essere facile o no. Inoltre, il MITM attivo non è possibile se il client utilizza anche un certificato (autenticazione reciproca) a meno che anche l'autore dell'attacco non abbia accesso a questo certificato. Con RSA invece, l'hacker deve solo ascoltare passivamente la connessione diretta tra client e server per decrittografarlo e farlo anche quando sono coinvolti i certificati client.