If you follow the references in RFC 8446, you'll see that it cites RFC 8032 for the definition of the EdDSA-based algorithms.
RFC 8032 in turn tells you all the details about the hash functions and other parametrization—field, curve equation, base point, encoding, signature equation, etc.—of EdDSA for Ed25519 and Ed448.
There are several roles for a hash function involved in RFC 8032: a prehash (peculiar to RFC 8032, added in order to placate users of shoddy designs that invite DoS attacks), a key-derivation hash, a per-signature pseudorandomization hash, and a message hash.
Ed25519 uses SHA-512 for all these purposes; Ed448 uses SHAKE256. But none of these choices concern you as a user of Ed25519 or Ed448: The choice of hash functions is a part of the signature scheme itself, not a parameter chosen or computed by a user.
The other signature methods in TLS are relics from days of yore when it was common to present users with a dizzying array of acronym soup options: Which mathematical magic do you want to use like RSA ($s \equiv h^e \pmod n$), ECDSA ($r \equiv x([h s^{-1}]G + [r s^{-1}]A]) \pmod p$), etc.; and separately, how do you want to be vulnerable to collisions in computing $h$ from a message $m$ like MD5, SHA-1, etc.? This era gave us delightfully nonsensical names like md5WithRSAEncryption
(a.k.a. 1.2.840.113549.1.1.4) for signature schemes.
The modern approach is to use a short name Ed25519 for a complete signature scheme on messages providing 128-bit security against existential unforgeability under adaptive chosen message attack, with all knobs and parameters and bells and whistles decided for you. An implementation of Ed25519 or Ed448 operates on bit strings of arbitrary length and structure, and does all of this hashing internally—in fact, it's not even defined in terms of a fixed hash $H(m)$ of a message; instead it's defined in terms of a pseudorandom function $H(k, m)$ of the message where $k$ is part of the secret key.