Let see if I can net this out:
1) (I think) Anyone who wants can create a custom X509HostnameVerifier that includes
if (socket instanceof sun.security.ssl.SSLSocketImpl)
But, they would be using an unpublished api (may break later), and would be dropping support for JREs before 7. They would also be using X509HostnameVerifier in a way not supported by the API documentation (setting something in a "verifier" - seems dangerous, even if it would work today.)
2) Reflection could added to #1 (as in the patch) to help with JRE compatibility. Any arguments against the suggested patch would apply here as well, but to a greater degree: users of HttpClient are a further step removed from the underlying TLS implementation, they are not necessarily socket programming experts, and the funny use of a "verifier" api.
3) The patch (or similar) could be applied to HttpClient. As in #2, JRE compatibility would be maintained. Leveraging an unpublished sun.x API isn't great, but it shouldn't break anything (if it's not there at runtime, SNI simply won't be performed.) Some dislike reflection, but without it, we can never leverage new features.
Through all of the prior discussion, I fail to see a concrete reason why the patch would cause problems. It may be aesthetically displeasing to some, but... what are the practical downsides? Pushing the burden of implementing this "TLS fix-up" to users of HttpClient has the practical downsides mentioned above and previously.