The "why bother" isn't very clear...
... and usually that means other unspoken agendas are busy. There's a few things I just don't get about Native Client:
- If its security model is working on x86 instructions, how is that portable to non-x86 machines?
- Given how new the verifying-instructions approach is, how can one claim it is secure? It's not been sitting there getting attacked yet - who knows whether there is a glaring hole that the researchers hadn't thought of? Only time will tell.
- The only thing I personally see as a bonus is that you can use a compile-checked and statically-typed language, something that I like better than the dynamic typing and loose OO of JavaScript. But you don't need to support native code to do this. You just need a different language, or simply get stricter with JavaScript, exactly like HTML5+CSS does to old-style HTML. The reasoning of "eases porting existing C code to the Web" isn't exactly inspiring.
On the surface, Native Client fills the same role as Java applets (speed + compiled code). However, it seems more likely to me that Google wants more speed to do things with their Web toys to make them more desirable than the competition's, and their tweaks of their JavaScript engine isn't giving it to them. Hence the Native Client idea.