A worthy goal, but I hope they don't let NIH set them years behind the curve.
Plus, the native code is nonportable and nonsandboxed. Portability might be the simpler of the two, but it is still not trivial these days to maintain a single C++ codebase across multiple compilers and OSes. Sandboxing is the big problem though: A fast ActionScript implementation must have a JIT, and JITs are extremely hard to secure. The browser already has a dynamic language JIT (for JS), so using that instead of adding an entire new one is far preferable. In addition, the C++ code must be secured too which takes effort and introduces risk.
So there are very good reasons for going this route. But I agree there are tradeoffs and benefits the other way too.
I don't mean to imply that this project isn't impressive -- it is. But I hate to see them duplicate so much effort for a solution that is, by nature, performantly disadvantaged. We need a serious challenger to Flash Player (we've had enough toys) and Mozilla is in a good position to provide that, so I hope they choose to do so.
>They don't include animations, they don't accept user input, they don't connect to servers and stream files and send updates
A PDF file is much more than just words and pictures. There are forms which accept user input, weird embedded content, and other strange things. Although I am not familiar with the spec, I have seen the features that Adobe Acrobat lets you do with PDFs and it seems pretty monstrous.
To clarify, there are several security issues that arise from all of this , and as others on this page have pointed out, that is a good reason to make use of the existing infrastructure around browser sandboxing.