Don't get it. If you are interested in the low level communications, why wouldn't you simply use a socket and send your own application defined commands over port 80?
HTTP exists so that any browser can access any web server, it doesn't re-implement or otherwise allow the usage of TCP/IP.
As a corollary, I don't see why I need to know about your application's communication protocol, let alone adhere to it because it's now a standard.
We are talking about bi-directional communications between the client and server. Specifically, server initiated requests to the client. So the major issue that you can overcome with this would be overcoming some NAT/firewall issues.
This proposal would be to convert HTTP from being a client making requests to a server to (effectively) a server making / receiving requests from another server. So your browser would also be a (mini) server, handling requests from the main server.
This is largely for people that want to use HTTP as a message-passing protocol, but use it in a bi-directional manner between possibly NAT'd hosts.
"This is largely for people that want to use HTTP as a message-passing protocol, but use it in a bi-directional manner between possibly NAT'd hosts."
That is exactly it. You've got it.
HTTP makes an almost ideal message passing protocol: it has a rich and battle-tested addressing model; it is asymmetric in a helpful way (really! the response codes are similar to ICMP messages, where the requests are similar to IP datagrams); it is widely supported and deployed; it is content neutral.
HTTP exists so that any browser can access any web server, it doesn't re-implement or otherwise allow the usage of TCP/IP.
As a corollary, I don't see why I need to know about your application's communication protocol, let alone adhere to it because it's now a standard.