Given Flash's atrocious performance profile, I'm surprised and impressed that this works at all. That being said, it chews an entire core on my computer to render the game at about 20fps, and the audio is nearly a half-second latent. Another way of looking at this is that Flash bytecode on a Core i7 today has caught up to half of where native bytecode on a Pentium I was 14 years ago.
I got 78.2 FPS on 'timedemo demo1', on an i7 920 @ 3600MHz, Flash 10.0.32.18, Firefox 3.5.5, Windows 7 Ultimate 64-bit. It was perfectly smooth. The audio lag (~200ms) seems more likely an architectural latency issue than a performance-related one.
It does appear to run without glitches. But your comment indicates that you never played the original Quake. Which ran at 60fps, software-rendered, on a Pentium I, with no audio latency.
Talk about nostalgia. I remember being 10 or 11 and playing Quake. I thought it was just absolutely amazing. I had also just gotten into the internet. The curiosity I had back then still exists, which is a good thing. The same feeling that we're just getting started still exists, even though things are so much more advanced.
My understanding is that the flash bytecode interpreter's performance is reasonable. Unfortunately the actionscript compiler does no code optimization. But this quake demo uses alchemy, which is LLVM based and offers significant performance gains.
The biggest bottleneck is rendering. When displaying flash content, your cpu has to render every pixel of every frame. The flash player vector capabilities are pretty extensive. Supporting image rotations, resizes and alpha transparency can require multiple cpu passes.
The obvious answer to this problem is GPU rendering. Adobe has made some efforts in this direction, but it doesn't look like it will happen any time soon. There are many issues that make this transition difficult. Backwards compatibility, cross platform compatibility, and reliability are a few that come to mind.
haXe does some additional optimizations over the Adobe compilers; however, the real performance difference in the Alchemy-based code comes from its original nature as C code: it works with bytes, not the AVM2 type system. You can access these special "fast ByteArrays" from both AS3 and haXe - haXe makes it a little more convenient - but in both cases, you're essentially writing C from a language that doesn't have C's features. (Alchemy has some interoperability features, so it's not a total one-or-the-other equation, at least.)
Rendering is the bigger performance culprit, anyway.
In addition to other reasons mentioned, Flash is also single threaded, so a lot of developers use pseudo-threading to get around this which is where a lot of lag creeps in.
