The distinction between open-source-but-proprietary and open-standard is important for many reasons. One of the most important is that open-source-but-proprietary protocols, if they catch on, end up devolving into bug-for-bug compatibility with a giant pile of C++.
By your definition Mozilla's (your employer's) asm.js and Rust are also proprietary.
Somehow I doubt that you jump on every thread about asm.js or Rust to point out how proprietary they are or how they are implemented as a giant pile of C++. Double standards.
There have been plenty of research and work even in standard bodies like IETF that try to implement a better tcp/ip-like protocol.
They all went nowhere because at this point in time, you can't just have some guys in a room to design a new transmission protocol and have it taken seriously by anyone that matters (Google/Apple/Microsoft/Mozilla).
Google is following the only realistic route: implement something, test it in a scale large enough to conclusively show an improvement and then standardize it.
This is exactly how HTTP/2 happened.
We should be cheering them on instead of spreading FUD because it doesn't live up to your impossible standard of non-proprieterness.
I think dragonwriter's sibling comment to yours is pretty apt here. It's hard to tell the difference between something that will be submitted to standards bodies any day now and something that really will be submitted to standards bodies any day now. At a certain point (with e.g. Pepper) the statute of limitations runs out and you have to assume it's just going to be an open-source but proprietary API.
Of course, whether or not overloading "proprietary" is useful is a different discussion. Mostly it seems these conversations eventually just devolve into arguments over definitions of the word for no real insight.
asm.js isn't a new protocol, and so isn't proprietary according to that definition. It's a subset of JavaScript (to be specific, ES6, including such extensions such as Math.imul). You can implement asm.js by simply implementing the open, multi-vendor ES6 standard. In fact, that's exactly what some projects, like JavaScriptCore, are doing.
Rust isn't relevant, as it's not intended to be added to the Web. Adding <script type="text/rust"> to the browser would be a terrible idea for numerous reasons. Nobody has proposed it.
"Proprietary" as used here isn't limited to the Web.
Things like the "Championed" proposals model for TC39 and (as DannyBee notes) IETF's approach to standardization are direct acknowledgements of this. In a way the Extensible Web approach is also a direct acknowledgment, insofar as it says that innovation happens at the edges, so browsers should provide minimum flexible building blocks and get out of the way. asm.js is a great example of using those building blocks (though it should be noted that as asm.js catches on, other browsers are forced to spend time on it, explicit directive prologue handling or no). Network protocols, on the other hand, are something that can't be built and tested from the tools browsers provide.
I think the better question for you would be, what's the better way to develop network protocols like this, then? Assuming that purpose, I can't think of anything to criticize here except maybe they should have limited testing to beta and dev users of Chrome. However, that limits your test data and normally that sort of thing is done to make sure web compatibility isn't broken in the future by changing standards, and given that browsers already negotiate protocols, I don't see an imminent danger there.
I think there is a distinction to be made between closed spec protocols and protocols developed prior to being submitting for standardization; while its hard to tell them apart prior to the latter actually being submitted for standardization outside of potentially misleading forward-looking statements of intent, the latter is a reasonable way of cleaning up something and getting some solid real-world feedback and proving utility before submitting something as the basis for standards work while the former carries the problem you describe.
I love Mozilla, but this seems like an apt description of "JavaScript." (sure, they're not so much bugs as misfeatures, but..)
By the definitions of proprietary floated here, every open protocol standardized as IETF proposal started out as proprietary.
The only thing that wouldn't seems to be "stuff designed in the open by committee". A process that has worked so well, it brought us things like C++ and POSIX.
