TCP != HTTP
HTTP/2 is implementing TCP's responsibilities. Again. Badly.
But of course, though we rarely worry about Token Ring these days, we do run TCP over IEEE 802.11 all the time.
Likewise, HTTP is run over other Transport Layer protocols even if it is less common, e.g. UPnP uses HTTP over the UDP transport layer protocol. http://en.wikipedia.org/wiki/Universal_Plug_and_Play#Protoco...
OSI's higher levels are abstractions. As is the case with all useful abstractions, they serve to implement the functionality of lower levels without requiring attention to their actual implementation. Not having to manage TCP allows a lot of useful JavaScript to be easily written.
There are upwards guarantees at each layer that the stack makes. All implementations within the layer must be equal to the next layer even if one of the implementations provides capability of higher layers. Nothing is said however about adding further guarantees in layers 8, 9, 10, 11, 12...and so forth because they have already been made.
I suppose I shouldn't use parity bits on serial connections then?
"Not having to manage TCP allows a lot of useful JavaScript to be easily written"
That's absurd. It makes no difference.
As for UPnP, which I know well having written an entire UPnP stack, it's a broadcast messaging layer, not a connection based protocol. All the HTTP messages stay within the size of a UDP datagram and it is expected to be wholly unreliable. Even though it's ugly, it's hardly a comparison.
I get the feeling a lot of people here are web developers with little experience of protocol stacks and not system programmers!
Back when we I had a 14.4k SLIP dialup and RTT of 200ms+ connection overhead and TCP channel overhead was a major drag on throughput but it's not like that now. I'd be surprised if there was a tangible difference to the end user.