In principle, if the server has a long-term secret exponent $s$, and a long-term public point $S = g^s$ that the client is willing to believe, then that's enough for the client to send a confidential authenticated message to the server: client picks $c$ at random, computes $C = g^s$, computes $k = H(S^c) = H(g^{sc})$, and uses $k$ as the key for symmetric authenticated encryption.
Unlike a signature, there's no third-party verifiability; anyone who can verify the conversation's authenticators can also forge them. If you want fast key erasure, then you can use this authenticated channel to perform an ephemeral Diffie–Hellman key agreement, as, e.g., the Signal protocol (technical documentation) does.
Why didn't we do this in, e.g., SSH and TLS?
Mainly for hysterical raisins, I expect. The use of signatures in TLS goes back to the original SSL, where I'd guess it was derived from the use of signatures in x.400 email with x.509 certificates.
For a certificate chain, you need a signature because you need third-party verifiability, and when you already have an authentication hammer, why bother devising another public-key authentication mechanism? Symmetric authenticators, i.e. MACs, as needed by a public-key authenticator using DH, were not really popular until the mid-nineties when HMAC was developed, even though the concept was first published in 1974.
Why don't we do this now in, e.g., SSH and TLS, using the public keys in certificates that are already deployed?
Many of them are RSA keys that are fit only for signature or (nonephemeral) key agreement, as in RSA key agreement, not for ephemeral Diffie–Hellman key agreement.* There technically are standards for x.509 certificates for static Diffie–Hellman public keys, but these are seldom used.
Why don't we use this in any protocols?
Well, we do. Public-key authentication without nonrepudiation didn't become popular until OTR in 2004, though proposals for it to replace email signatures date back to 2000. The dnscurve protocol was designed around fitting a server's long-term X25519 public key in a tagged DNS label so that you can compatibly fit it into a standard NS record. The Signal protocol uses long-term DH keys for authentication extensively. The Noise protocol framework doesn't use signatures at all at the moment; all authentication is via long-term DH keys.
Why don't we retroactively use it for protocols that already have Ed25519 keys deployed for signatures?
We could, e.g. using XEdDSA, but someone would need to implement it to make it happen. I can't speak for all protocols out there! Will you send the patch to OpenSSH to implement public-key authenticators using XEdDSA for deployed X25519 keys, and argue on the mailing list to justify the additional complexity, when signatures already work? When you design a new protocol, will you use long-term DH keys for authenticators instead of signatures?
Note, of course, that merely using long-term DH keys for authentication doesn't allow key erasure because the keys are, well, long-term. So for fast key erasure, you still have to compose it with ephemeral DH keys, as I summarized in a recent post on an idealization of how WhatsApp works.
* Here ephemeral means that the keys can be erased after a session and all its resumption tokens have been erased, so compromise of the server's long-term identity key doesn't enable retroactive decryption of past sessions. This property is sometimes called forward secrecy, a term that glibly obscures when the erasure happens, which is particularly important to take care of with TLS resumption tokens.
