I'm personally optimistic that in the future, once we found a wide permutation of sufficient efficiency, we'll be more motivated to define internet protocols (for example, TLS 1.4 or 1.5) to be parameterized exclusively by the permutation it uses.
Following the format of the answer by SEJPM,
A symmetric cipher suite defines the the pair of the AEAD algorithm and hash algorithm to be used with HKDF.
First, the AEAD algorithm can and have already had been defined in terms of a mode of operation of a permutation.
Secondly for key derivation, it's the hash algorithm to be used with HMAC for instantiating HKDF. As already noted in the OP, there's already KMAC. HMAC requires at least 2 invocations of the hash function, so it's plausible we may want to replace it with special designs that're specific to the underlying primitive to obtain more efficiency - for example, KMAC as in the case of Keccak, or Keyed BLAKE2 in the case of ChaCha (the latter of which is unlikely since the ChaCha function is slightly different for the cipher and for the hash).
Thirdly, we may not need dedicated MAC if we can prove the tag of the AEAD algorithm is computationally random, and can obtain arbitrary-length tag from it. In this case, even the HKDF construction is partially redundent, as in the extract and expand steps are preserved, but they no longer rely on MACs.
Additional points go to the answer that also
manages to indicate a method of authentication (hash-based signatures?)
Of course hash-based signatures. As already mentioned by SEJPM, Keccak-based hash functions had already been proposed to instantiate the SPHINCS+ signature. What I'd like to add, is that the actual SPHINCS+ and its underlying XMSS and WOTS signatures rely on randomized and parameterized hashing to reduce the size of the signature, these signature schemes may benefit from hash functions instantiated from e.g. TupleHash as specified in NIST SP-800-185 in terms of performance and bandwidth efficiency.
Also, there's the stateful hash function that are slightly more efficient than the stateless ones. According to NIST, they intend to approve stateful hash signatures in some applications, including for example: code signing. Similar applications could potentially include OCSP the Online Certificate Status Protocol, and CRL the Certificate Revocation Listing, as these data change much slower than ephemeral key-exchange public keys.
and, possibly more tricky, a key agreement scheme to replace (EC)DH.
I agree with SEJPM in that asymmetric key exchange is improbable with hash functions, or symmetric-key primitives in general.
While TLS do have the option to use Kerberos for handshake, after quickly going through RFC 4120 and IANA registery for Kerberos 5, I realize that Kerberos is a protocol with so many legacy artifacts that, if we were to advocate Keccak for the protocol, it would cause massive incompatibility and interoperability problems with existing implementations.
The idea of Kerberos is still applicable, in that in a large network, KDC can maintain a database of keys for the nodes in the network, and lifts from each node the burdon of maintaining PSKs for all peers.