#0 and #1 are intrinsically part of HTTPS
#2 and #3 are just because Google and browser vendors simply limit these things to HTTPS. It is not like it can only come with HTTPS.
Finally, #4 is a side effect of #0.
So the only thing really provided BY HTTPS is encryption and authenticity.
E.g, you run an online video company, and (for some silly reason) you don't care about privacy. You still don't want T-Mobile turning your great HD content into a low resolution blocky mess.
Edit: actually, thinking about it, you're right. I've updated the article to use the word 'privacy' to better separate it from the other aspects on encryption. Thanks datalist!
True for "signaling value", but for powerful browser features that the user grants or denies on a site-by-site basis, there's a critical reason to only allow those for HTTPS. If you allow those features for HTTP, you allow them for anyone who can MITM your connection and spoof those sites. Any random ISP, open wifi, or other entity could trivially MITM a popular site via HTTP and obtain privileges it should not have.
If a user is MITM'ed, it doesn't matter if some features are disabled. The attackers can do anything they damn well please, like directing the user to a compromised HTTPS site to access those features, or to a drive by download to do worse things.
Concrete example: geolocation permission. You visit some popular mapping site that uses HTTP, and grant it persistent permission to use your location. Later, you browse something else via HTTP over a Tor connection. In that browsing session, if you saw any permission prompt for geolocation, you'd reject it. However, a malicious exit node could MITM you and use that to determine your location by pretending to be the mapping site, without a permission prompt.
Ditto for getUserMedia (webcam/audio), fullscreen, and any other permission a user can grant or deny on a site-by-site basis.
So, browsers want to drop the possibility to use those features from HTTP, not just to push sites to HTTPS but because the entire concept of granting permission only to a specific site doesn't doesn't work with HTTP.
Pinning makes that even more secure, but even without pinning, requiring HTTPS raises the bar from a simple MITM to obtaining a fraudulent certificate from a trusted certificate authority (risking a blacklist of that CA in all browsers).
If the attacker MITMs an HTTPS request, then they have to provide a forged certificate (whether HSTS is set or not).
If the attacker MITMs an HTTP request which would have normally been redirected (e.g. typing "facebook.com" into the URL bar), then HSTS is required. Without it, no forged certificate required.
HTTPS and HSTS should have just been the baseline the web shipped with, but the web shipped before people thought about these things, and arguably before encryption was stable/secure/fast enough to be practical for the whole web.
I'm very happy that the federal HTTPS-policy includes an HSTS requirement for federal agencies: https://https.cio.gov/
However, even if the attacker MITMs an HTTP request that would have been redirected, for a site that didn't use HSTS, they won't get cookies marked "secure", and they won't get permissions that require HTTPS. So the browser mechanism limiting those permissions to HTTPS still works even in that case, though the user and site both have other problems.
The cynic in me is thinking "hey, funny that a company selling SSL Certs wrote an article about how great SSL Certs are which doesn't do much more than state side-benefits to one primary benefit of having SSL"
HTTPS gets you privacy, tamper-resistance, and authenticity for the end-user.
This is the one that I often forget: just because something is encrypted doesn't mean it can't be meaningfully manipulated without knowledge of cleartext.
Seems like a pretty real and legitimate reason to me.
Sure, but HTTPS doesn't provide it. I mean, not really. HTTPS is the flag by which browser manufacturers have toggled the behaviour.
This is just pedantic.