Letting the browser abstract away video playback, doing whatever's optimal on the target hardware (hardware acceleration, optimized SSE/NEON vector instructions, and so on) will always be better than decoding in software, and the functionality already exists for us via the <video> tag - decoding via JavaScript is in many ways a big step backwards.
I understand that a JavaScript VP8 decoder provides greater cross-browser compatibility, but personally I think it's worth the overhead/cost of encoding and storing both H.264 and VP8/WebM versions of videos in order to win sane mobile playback and reduced CPU usage on the desktop (via hardware H.264 acceleration).
Plus, this decoder doesn't consider audio, as far as I can tell. HTML5 provides very bad support for programmatically-generated audio with strict time constraints - this is a common problem with writing HTML5-based games as well and I can't see any way that any browser today could produce adequately synchronized, real-time audio along with video rendered to a canvas.
This is an absolutely awesome piece of code, and the hacker in me loves it, but I don't think it's practical in real life. It might have limited use in audio-less product demos, page banners, and the like, but for legitimate video playback, I think the <video> tag combined with a flash fallback is vastly superior, even when the need to encode the desired video to both H.264 and WebM is taken into account.