HN user
IPSec doesn't support authentication well. For example, if you have a shared secret like a web cookie, how would you use this to authenticate one endpoint of an IPSec connection? It's hard, because the granularity of IPSec session keys is not the same as the granularity of tcp connections. Tcpcrypt, by contrast, makes it easy to do this--just hash the session ID together with the other authentication data.
If you use X.509 server authentication with 2,048-bit RSA keys, tcpcrypt offers about a 25x speed-up over SSL for equivalent security. (Actually slightly better, since tcpcrypt offers forward secrecy while, in the benchmark, SSL does not.) The key optimization is batch signing, where a single RSA signature can authenticate a bunch of connections at once. There are graphs showing this in the paper and talk slides.
A lot of the SSL vs. SSH discussion on here is just demonstrating the fact that there is no one-size-fits-all solution for authentication.
The point of tcpcrypt is to get the best security possible under any setting, so it can be used with both SSL- and SSH-like settings. See slide 5 of the talk on the web site:
http://tcpcrypt.org/tcpcrypt-slides.pdf
One thing I haven't seen discussed yet is that fact that come October, the EKE patent is going to expire, which means that all of a sudden it's going to be legal to do strong authentication using only human-chosen passwords. Strong password authentication is desperately needed, because people overwhelmingly both chose week passwords and don't think carefully about where they send those passwords.
Somewhat independent of tcpcrypt, section 4.3 of the tcpcrypt Usenix paper suggests a nice and simple secure password-authentication protocol. Deploying such a protocol would make a huge difference, except... what are you authenticating? You can prove possession of a password, but this doesn't actually protect you unless the authentication is tied to session traffic, and you are authenticating communication endpoints. SSL, IPSec, and even SSH don't provide adequate hooks for doing this (though SSH would be easier to retrofit than the other two). Tcpcrypt does.
So the way to view this is that in the absence of authentication, tcpcrypt will be vulnerable to MITM. But as soon as you go to authenticate yourself to a server (by typing a password or verifying a certificate), the authentication will fail, and the MITM will no longer be able to deceive the user.