WebGL is interpreted? What do you mean? Modern JavaScript runtimes are DEFINITELY not interpreted, and the idea of an interpreted graphics API or GPU is nonsense.
I'm not going to get into a semantic argument, perhaps to you Java is not interpreted either, but to me anything that doesn't compile to a binary directly executable on the CPU is substandard in terms of performance. And I'm sorry to surprise you, but in 3d graphics we're still starved for processor cycles, otherwise we'd have ray-traced, globally illuminated games with huge environments to play with.
It's JIT compiled and WebGL shaders are compiled as well. It is a native code executable on CPU, read how Crankshaft in V8 works.
It's true that JS is at the moment N times slower than C++ (N in range 1 to 10). It's not true that you need to use JS that much to have great graphics. Everything you pointed out is done on GPU afaik.
And if you wait a year or so, JIT + type inference will make JS basically as fast as C++.
Well, I'm not that familiar with the internals of JS engines, perhaps some browsers are capable of partial compilation. On the other hand, this is a dynamic language (as in: data types and other pieces of code can change in run-time), with limited features, like data structures (wanna benchmark linked lists or kd-trees in C++ vs JS? I doubt N=10 is skeptic enough). I'm not sure if I write path-finding or collision detection or line-triangle intersection with their respective data structures in JS, it will turn out anywhere in the ballpark of real compiled code. (And this is pretty elementary stuff in 3d games.)
Now we are getting somewhere ;) Graphics are not an issue, physics may be. Still, you would be surprised how fast compiled JS can be. It requires some discipline but if your code is good, performance is not that bad. And some data structures are actually waaay easier and smaller in JS (e.g. graphs). These are pros and cons of high level language.
By the way, there are also typed arrays which are translated directly to native code and were designed with WebGL in mind. I'd say that garbage collector is now the biggest issue of JS games. But it's improving, don't be skeptic.
EDIT:
Actually, I did a small lecture a week ago, about performance tips. It's probably far from perfect as I don't work on browser engines, but it may give you some hints about making JS performance C++-like.
http://www.smashinglabs.pl/lectures/js-performance/
I'd say that's an absolute minimum in terms of sophistication. And yet, some of it barely runs on a modest hardware setting. (Core2duo 2.5GHz, GF 8600GT.) [EDIT: Well, OK, in Chrome it runs OK, but still, these are tiny windows. Full-screen wouldn't be so nice.]
Now, imagine that you want to write an MMORPG. You make it just a little prettier than those demos, but more importantly - expand the world and add many more characters. It would bring _any_ gaming rig to a halt. (And yes, I realize that you don't display the whole world at once. But still, you need much more than there is on these demos.)
I dzięki za linka, fajne rzeczy na SmashingLabs i AiGameDev. :]
These demos run perfectly well on my Intel card. There are also interactive music videos like http://www.ro.me/ or http://lights.elliegoulding.com/ which are running fast enough. OpenGL ES is almost the same as OpenGL, the only feature I've found missing so far was geometry shader.
What in my opinion stops graphics from being better is model size that has to be transferred. You wouldn't wait 2 hours for game to load, would you?
