I agree encryption is something that should be mandatory, but you can't pin down an encryption algo to be used by HTTP/2 without allowing for future changes..
I think you should always be able to turn encryption off. Encryption is expensive. I run OpenSSH-HPN partly so, on my local network I can get secure logins but then not pay the throughput hit of encryption when it just doesn't matter. The same even applies to internet connections, such as big but generally uninteresting things like log files.
Defaulting to "encryption enabled" and throwing a browser warning of "encryption disabled" makes perfect sense, but you definitely should be able to turn it off for content where it doesn't matter.
I'm impressed I'm somehow getting modded down for that opinion.
My local network is trusted. Google does not have a local network. But the cables and wires physically within my house or even my office building can be presumed to be secure, since if you can get access to those, then you could also just take the physical machines by any numbers of methods.
You also don't address "large but insensitive data" - which is where YouTube video downloads and the like mostly lies. Encryption is not costless on small devices like laptops/desktops.
Considering that your local network is trusted defies "defense in depth" - do you use Telnet for your admin? What happens with your Wifi, or if one of your computers gets pwned and starts becoming a packet-sniffing machine?
Google feel it's potentially sensitive data. After all, it's showing what you're reading, what you're downloading, what you're seeing.
Laptops/desktops are way too big to feel any noticeable effect from modern encryption: that's nonsense, look at the benches. You won't even feel that impact on a Raspberry Pi (actually the VC4 is surprisingly good at some crypto - I'm halfway to a ChaCha implementation on it, if I can just sort out the diagonal round permutation!). TLS 1.2+extensions and 1.3 will have things which make good encryption even faster: the use of fast AEADs like AES-GCM and ChaCha20-Poly1305, and ECDHE using Curve25519, etc. This decision is underpinned by, and supported by, all that work.
If your use case was toasters and 8-bit microcontrollers (as opposed to 16-bit or 32-bit AVR-type ones), then you'd have a discussion, but I've seen efficient Atmega implementations of this, I could probably cook something up for a 68000 myself, and anyone who really fancies a challenge should go for a 6502 or z80 implementation. I'd simply respond that lack of privacy is not costless, and you've really no excuse anymore.
Try using SSH for big file transfers. Oh right - you don't - because the throughput is CPU limited by the encryption. Multithread it? Sure, now watch as your 8 core machine peaks pushing a gigabit of encrypted data which is actually just an image file of a movie you already have. You encrypt credentials (because they grant access) and sensitive data - like bank details. You don't encrypt the legal rips of movies you have streaming over your network because hey, that would be a complete waste of energy and processing power for literally zero-benefit.
Always on encryption is pointless and the type of always on encryption with HTTP 2 people talk about is worse then pointless. The idea that MitM is difficult is a farce - any number of WPS hijacking techniques involve forcing the host offline temporarily so it has to re-authenticate. The same thing would apply here. Taking what, 2 seconds?
You talk about defense in depth - one aspect of that is that a leaking side-channel has finite bandwidth and can't possibly hope to capture "all the data" which means it has to try and capture important data.
