[geofft]

Integrity protection. There are a lot of ways to instruct someone to configure their web server in a way that is subtly insecure, not to mention attacks like http://thejh.net/misc/website-terminal-copy-paste

It'd be slightly nice if we were able to have integrity-protected HTTP without encryption (lower overhead, easier debugging with packet dumps), but the advantages are minimal (ciphers are not really the overhead, SSLKEYLOGFILE is a thing) and it's a lot of complexity to the web platform, which is a downside for web developers like you and me: the rules for mixed content between HTTP, HTTPI, and HTTPS are going to be much more involved and confusing.

[Franciscouzo]

You can already send unecrypted authenticated data with HTTPS.

[geofft]

Via one of the NULL-cipher suites? That's a somewhat expansive definition of "can" and "HTTPS," since most if not all browsers are unwilling to negotiate any of those suites. Indeed, most SSL libraries make it hard to use those suites: for instance, OpenSSL says (`man ciphers`), "Because these offer no encryption at all and are a security risk they are disabled unless explicitly included."

Which makes sense, since they'd have the exact same problems as an explicit HTTPI protocol, just even more confusing: you'd want to not send things like secure cookies across those ciphers, you'd have to handle mixed content with actual-HTTPS carefully, etc.