No SNI on Windows XP (IE6, IE7, IE8, Safari), nor Android 2.3 Browser, nor BlackBerry. Windows XP still has 4-5% usage share on the web, which is 1 in 20 people. Lots and lots of low-end and older Android handsets were on 2.3 because 4.0 had new hardware requirements. Combined, it's a relevant number of people for large sites.
> Windows XP still has 4-5% usage share on the web, which is 1 in 20 people.
Chrome and FF together have a market share of about 70%, so roughly speaking, only 30% of those XP users can be expected to still be using IE or safari. The percentage might be a touch higher as users left on XP might be less likely to use a different browser, but it's certainly not like all of today's XP users are on IE + Safari.
You know how Mozilla recently had to delay the SHA1 deprecation in Firefox because it broke people behind shitty MITM "security" solutions? That crap often doesn't support any "modern" TLS features like SNI either.
Windows XP. Python through about 2.6. Java until quite recently. Old Perl code that I shudder to think about.
<shudder>
Oh, and some old Android. The Android version that started supporting SNI is apparently also the version that tightened up licensing, so a number of third-world forks still use the old version. And as long as most of the web works without SNI, they don't have a huge incentive to change that.
The work that some browser vendors (Mozilla, Google) are doing to privilege imperfect-TLS over no-TLS is crucial here. Also, yes: new Web work should all be done over HTTPS.
some pretty modern languages / libraries don't have SNI built in. E.g. requests under python 2.7 doesn't do it by default. As for browsers, I think the answer is that most do - it ends up being something like IE on XP and really old Android that gives you trouble.