Using Kerberos as originally intended, meaning that you exchange AP messages (or GSS-API security context tokens) to authenticate and set up session keys, which

Using Kerberos as originally intended, meaning that you exchange AP messages (or GSS-API security context tokens) to authenticate and set up session keys, which you then use for session protection using KRB messages (or GSS-API per-message tokens), then it turns out the vast majority of applications don't even need replay caches. The reason is simple: most application protocols follow up the exchange with data that is not sensitive to replays. Relatively few application protocols actually use Kerberos as originally intended though. Many SASL apps run over TLS and don't use Kerberos for session protection, for example, in which case you have to make sure that the server certificate PKI is as good as Kerberos (this is not a big deal in corporate networks). And HTTP/Negotiate uses Kerberos as a bearer token. There are some extensions to do channel binding of Negotiate tokens to TLS, but those are not universally easy to use because of complications to do with reverse proxies and less-than-universal client support. Anyways the "dialogue" exposition is pretty neat and stands the test of time.