In general, I understand that nonces are used to prevent replay attacks, but in the case of a TLS 1.3 handshake, the Client/Server Hello message contains their public keys. Considering that keys are randomized every time (as in the case of Ephemeral Diffie-Hellman), don't they act as a "nonce" for the communication already?
What would be the security implications of reusing nonces from one connection to another in this case?
In the "standard" case, the TLS 1.3 handshake includes an ephemeral Diffie-Hellman key exchange which makes the nonce not absolutely required.
One reason the nonce is still there is for compatibility with previous versions of the protocol.
When using a PSK-based handshake, the Diffie-Hellman (DH) is optional: when using psk_ke, no Diffie-Hellman key exchange is done. In this case, the usage of client and server nonces in the handshake prevents replay attacks and prevents the session secrets to be the same in multiple TLS sessions. However, psk_ke should be avoided if possible (because it does not provide forward secrecy).
Moreover, due to the presence of the random nonces, a server (or client) could choose to use a static/long-lived DH keypair instead of an ephemeral/single-use one. This approach is not recommended because it breaks the expectation of forward secrecy provided by this DH key exchange: it does not provide forward secrecy with respect to this long-lived DH private key. However, this approach has been proposed (for example in an ETSI standard and a NIST draft) as a solution for allowing passive (or active) monitoring of TLS traffic in a datacenter: in this approach, each TLS server in the datacenter is provisioned with a static DH private key which is shared with the monitoring infrastructure.
