Certainly true if you don't need them. However since code using the library as a TLS client is already partially present, support for certificate verification is definitely going to need to be added.
At the moment, I'm not that impressed with the testing since even making it build actually requires patching it! This is just due to one of the examples, but from the git history it's been broken since January.
Other than the government, nobody trying to do client certs actually runs the CA that issues them that I've seen. Instead, they trust some random set of commercial CAs, ignorant of the fact that openssl s_client -connect will dump out that list to any passer-by. I've even seen them trusting the "domain control validated only" certs, without any indication of "maybe this is a bad idea, because anyone who can buy a cert can auth to us because we don't even check."
So for every case I've seen, they'd have been ahead to issue credentials themselves and just skip client certs.
Thank you for the vote of confidence, but you're wrong. The question of "real world usage of TLS" is one where I would immediately defer to tptacek without question... and you've been around long enough to know that's something I don't do very often.
Eh, just dumping X509 for something easier-to-parse would cut out a huge chunk of code. Being compatible is hard, but we stick with what we have because of switching cost, not because it's the best we can do.
