> What I can't think of is a realistic scenario where it's possible to validate the session id in a secure way, but there is also some reason that we couldn't just use TLS with client certificates.
TLS with client certificates requires securely getting and certifying the certificates. Somehow. Yet many alternatives exist.
For some applications keys might exist in dns-- but in others no dnssec or names could be assumed.
For some applications the endpoints can be assumed to have a shared password, so some SPAKE can be used to authenticate.
For some applications an identity exists in some external consensus system that the other side can provide proof from, but which doesn't fit into the x509 model. (For example, if you wanted to use keys registered in namecoin to authenticate your identity).
For some applications you would like to use an anonymous group signature: "This user is on the authorized list, but beyond that, I don't want to know what user this is."
For some applications each party should be cryptographically unidentified, anonymous, and indistinguishable to from any other party unless both of their keys match, because otherwise you could track the parties around the internet from IP to IP. TLS/client cert lets you achieve this for one side-- you can decline to send the client cert if the server identity isn't to your liking, but you can track the server's identity around.
None of these examples fit nicely into the TLS/x509 model. All of them, including something functionally equivalent to TLS+x509clientcerts can be implemented on top of TCPcrypt.