Given that letsencrypt exists, I don't see why you wouldn't have a cert.
> Maybe you just have a pre-shared secret or a kerberos ticket.
The pre-shared secret could be a cert which would work with TLS.
> Or worse, maybe you just have a password, and so need to use a PAKE protocol or something to authenticate the session.
I can't think of a realistic example of such a protocol. What protocol uses PAKE, but doesn't support encryption, but will verify a session id? It seems like using TLS would be simpler.
> Or maybe you are using an RPC protocol, like NFS, that doesn't let you add TLS in a backwards-compatible way, but where the client and server do share some secret file handle.
Such a scenario still requires modifications to the NFS server and client software, which, if done, isn't clear why it would be better than just layering TLS onto the protocol.
That makes an enormous number of assumptions-- that you have a domain name, that you accept inbound connections, and that "gee some server connected to my name and got me once" is a remotely acceptable criteria for identity in your application.
An example would be if you don't have a certificate. Maybe you just have a pre-shared secret or a kerberos ticket. Or worse, maybe you just have a password, and so need to use a PAKE protocol or something to authenticate the session. Or maybe you are using an RPC protocol, like NFS, that doesn't let you add TLS in a backwards-compatible way, but where the client and server do share some secret file handle.