Chrome and Firefox will still insist on TLS for HTTP/2. In addition, the HTTP/2 spec does mandate that any implementation must support TLS 1.2 and up, and it must support forward secret ciphersuites.
The big pushbacks came mostly from middlebox-makers, proxies and the like. Unsurprising.
The market will decide. I'm sure the remaining browsers will make their own decisions, and I expect Opera and IE to fall on the TLS side, and then the decision will be effectively made.
The TLS WG will watch the result with interest, I'm sure, looking forward into TLS 1.4/2.0/whatever...
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.
So did Google. It isn't.
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.
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.
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.