All right, I'll (tentatively) buy that. It'll be interesting to see how Pepper stands with regards to documentation when NPAPI is deprecated. The other thing that bothers me about Pepper, though, is that it's a new way to create plugins. That's a step back, IMHO: the death of plugins is a Good Thing(tm). The Chrome team should be concentrating on the open web platform. Instead of writing a 3D abstraction in Pepper, work on WebGL. (The other thing is that Pepper is strongly tied to Native Client, which I disagree with a lot more: NaCl, in addition to confusing me when we talk about salt in chemistry class, really strikes me as a step backwards from the open web platform. Tied to x86? Come on. PNaCl is better, but not by much.)
And while I'm complaining about Chrome, you should open up your app store and your apps. *Clue:* Chrome is not the only browser out there that has support for offline apps or a bunch of other things. Firefox has done AppCache since version 4 or something. And yet Chrome Store apps, if they use offline capabilities, "need Chrome".

I agree with some of your points, especially regarding SPDY. But I have to put this out there: Pepper is not a real API. PPAPI is essentially just a crapton of exposed inner Chromium guts. There's a reason that other browser vendors don't support PPAPI: it's because the only realistic way to implement that support is to pull in half of the Chromium sources, then keep up with changes. That's insane. You can't expect people to do that. Not only that, but the PPAPI doesn't exactly have great documentation, either. Unfortunately, I can't name a specific reference for this, but reportedly, over 50% of PPAPI calls in Adobe's Pepper version of Flash are undocumented. I'll fully admit that NPAPI has problems, but that doesn't mean that PPAPI doesn't also have very serious issues. See also the Mozilla bug on implementing Pepper support: https://bugzilla.mozilla.org/show_bug.cgi?id=729481