See the following video from the recent LLVM Developers' Meeting
Portable Native Client, David Sehr, Google [mp4,269mb] http://www.llvm.org/devmtg/2010-11/videos/Sehr_NativeClient-...
The problems with Native Client go beyond its currently x86-specific nature though. The Web is based on open standards, and a requirement for most standards is having multiple independent implementations. Native Client is a complicated enough technology that it might be completely impractical to spec it in sufficient detail and independently reimplement.
You might think this is only a technical issue of standards process, but a standard with only one implementation ends up de facto controlled by a single entity, even if the implementation happens to be open source. In practice, you'll get support for the platforms and CPU architectures that Google cares about, in their priority order. You can see how that might not be so appealing for an entity that doesn't want Google to be setting the agenda quite that much.
In addition to this, the security architecture of the whole thing seems pretty dubious. It does have a better attempt at security design than ActiveX. But given the basic approach (binary-level validation of binary code), it has a lot of attack surface.
All that being said, it's a neat project with a lot of hack value. It just doesn't seem like a great fit for the Web. It is likely more driven by Chrome OS at this point.
And if a single implementor is a bad thing, shouldn't you want Mozilla in on it?