The question is not "how many polygons can you render?" but rather, "how many polygons do you need to render to provide the desired experience?"
So it's a threshold question, not a contest where the winner is determined by benchmarks.
I think a more honest comparison (in theory) would be to compare a site used to serve music with spotify. For those that use spotify a link that opens up spotify is probably vastly superior to anything a site can do, that's not to say that the site itself doesn't have any value. But the act of playing music is something spotify better at - and that mainly is just because (if you use spotify) you have your music collection in one place. That's where you go to play music.
Playing a game locally doesn't have to be more than pressing an hyperlink. Steam is probably the, currently, best place for this but, I know, relying on something such as spotify, steam or flash sucks. But there is nothing to say that we can't have an open android/iOS-market-like place for doing this. Apple and Microsoft will push their own markets and I'm surprised that the notion of a third party market hasn't come any longer than steam. I guess people are just too greedy.
There really shouldn't be any reason for why running it in the browser should be any better than running it locally. Have sandboxing as an option (or requirement), similar to what apple does, and go nuts.
I miss the days when running low-level code in an all-purpose browser was something that was considered moronic.
Perhaps there shouldn't be as much friction to install a game as going to a web page, but you can't deny that installing a game is currently not nearly as streamlined and easy as clicking a link. Even though it could be, or even should be. The main issue is that you have to wait to install the full game. A WebGL game would instead just download the minimum required to play the first level, and get you started playing the game ASAP.
The other thing though about a game being tied to a link is that it becomes a part of the web. Others will link directly to the actual game, rather than a page that lets you download/install the game natively. This ease of sharing is what makes it really powerful to have an in-browser game. The web is simply the ultimate form of distribution. It also seems less invasive compared to installing - you are not making any changes to your computer. Just close the web page, and it's gone (ignoring cookies/cached files). Whereas a native game will create all sorts of shortcuts and basically embed itself into your system. This is more of a perception problem with "installing" in the eyes of the average consumer.
And nothing you said has anything to do with WebGL. See android market where you can install apps from a web page. See Origin, launch games from the browser. Installing, running an native game doesn't have to be more than answering "yes" to the question "do you want to play this game?". And I have a hard time seeing how it should be harder to uninstall than a game utilizing WebGL and local storage...
Keeping the game sandboxed and basically treating everything that is downloaded as a cache - no problem.
And streaming content to a native-game isn't exactly rocket science either, there just haven't been a need for it when you still have this cumbersome install process that you have today.
Do this and you would get an awesome separation of performance critical low level code and the web resulting in a vastly reduced attack vector (basically going from push to pull). As a bonus you would get much better performance.
You mention Spotify, I think Pandora is a great example of overcoming that feeling of commitment. If I go to the Pandora website I can listen to music right away by just typing in an artist. If I go to spotify I need to download some client and who knows how hard it will be to get rid of. If I complete the downloading step then I need to sign up for the service (I know they changed it to facebook login recently so I don't know if it's the same) just to start listening. I don't even know if I will like the service at this point because I haven't even got to try it yet. I think I would describe this as friction.
Installing spotify is a commitment, but if you already have spotify playing a song in spotify isn't a commitment even though that means that spotify will have to look it up and download it for you.
Yes, you already have a browser installed. But soon you will most likely have a "market" installed as well (in a few years you probably have to actively avoid it if you don't want it bundled with your OS). The market just have to make a distinction of apps that are "light" and doesn't bloat the system. It could even remove it automatically after x days of not being used. Similarly to how spotify would cache a song you downloaded. Or a browser does... (hello html5 and local storage)
Compare with smartphones where they did this distinction by calling applications for apps instead.
Spotify is worth installing because it gives me all music in one place. If I had to install one app per title, I would not consider it at all. That is how games are. You have to install each title individually. That makes Spotify much more similar to the browser than it is to installed games.
But you don't feel like you are installing google just because you go to google.com are you? Doesn't have to be any different for games. Well, the difference is that a game probably have a lot more content but that's nothing you get away with just because you use WebGL.
You only have to install one application that handles all your games (or applications) just like spotify handles all your music and your browser handles all sites.
The experience today for serious 3D games is, a full install for each game. Platforms like Flash and Unity attempt to do what you say, be the 'spotify' of games, but in general game devs ship their own proprietary native code.
I agree on mobile/tablets the existence of an app store infrastructure is more 'web-like' than the experience on desktop/laptops. In the end, this is a bit of semantics -- Google's native client stuff is probably the ultimate solution technically, sandboxing full-speed native code instead of relying on Javascript for client logic. However that is farther down the pike in terms of cross-platform adoption than webGL.
It all comes down to a tradeoff between adoption and bleeding-edgeness. My argument is with regard to what the situation will be if/when webGL is running on 90+% of browsers, including mobile and tablets.