The first one I see where this defense would actually be helpful is the "September 23, 2003: Portable OpenSSH Multiple PAM vulnerabilities", which only applies against a nonstandard PAM configuration, where enabling PAM at all is something openssh doesn't recommend. The next is "April 21, 2002: Buffer overflow in AFS/Kerberos token passing code" - again, an obscure login protocol that's disabled by default.
The first vulnerability that would affect "normal" users is the "Feb 8, 2001: SSH-1 Daemon CRC32 Compensation Attack Detector Vulnerability", 11 years ago. Even if you want to count the "nonstandard config" vulnerabilities, we're still talking 8 years since any real attack, for possibly the most high-profile encryption software in the world. That's a track record I'd put more faith in than spiped's.
If you want to secure your openssh you'd get a better return on your time (IMO) by disabling any login methods you don't use (or, even better, switching entirely to single-use keys), and rate limiting login attempts from a single IP.
Having said that, the vulnerability you pointed out was in SSH1, right? Isn't that depreciated?
It is now. I'm not sure it was in 2001.