Interesting. The paper was released before HTTP/2 was in widespread use. They do show that their approach has significant improvements over SPDY alone...I wonder how the comparison to HTTP/2 alone would fare.
On that note, I do think it's a bit inaccurate to say that Google's efforts are/were primarily focused on data compression -- yes, they did introduce brotli, which is just a better LZ77 implementation (primary difference with gzip is that window size isn't a fixed 32KB), but they also pioneered SPDY (which turned into HTTP/2 after going through the standards committee) and now QUIC.
(obligatory disclaimer that google gives me money, so I am biased)
Edit: Should note that I'm excited about QUIC as well, just thought I may have been missing some new development where it's (already) more usable outside Google's walls.
I realize that the initial RTT reduction isn't so relevant in the context of large dependency graphs, but especially in the context of packet loss, the proper multiplexing across flows seems useful.
There are also a number of other QUIC-based features that might be relevant, since it does essentially reimplement the relevant parts of the TCP stack, so parameter choices might be better suited to today's internet (as opposed to 1980's).
More efficient protocols might reduce the disparity, but there should always be one. Right?
Given that Polaris has some downsides, it might reduce it to the point that you wouldn't consider it. In it's current state, Polaris requires a lot of pre-work...including dependency analysis via a real browser. It also serves up pages that wouldn't work with javascript disabled, and might not be terribly search engine friendly.
http://blog.httpwatch.com/2015/01/16/a-simple-performance-co...
I don't think server push was used in this benchmark, it's arguably a poor mans way to achieve part of what's discussed in the referenced paper (serving early dependencies...early).