The basic complaint is that NaCl is architecturally tied to 32bit x86. It relies on segmentation (bounds) checking that no longer exists on amd64, and perhaps more damningly, it's tied to the Intel instruction set altogether.

PNaCl is basically the same idea but built on top of LLVM's bitcode format (sortof a portable "high level assembly" representation of a program).

Personally except for the segmentation issue, I don't see bitcode as particularly compelling over x86, since the latter is already ubiquitous, and the other major issue with x86 that'd prevent efficient use on other platforms, that of instruction alignment, is already expressly prohibited in NaCl (in other words it should be easily possible to statically translate an x86 NaCl executable to run on ARM or similar, without all the overhead of runtime translation e.g. VMware). I'm guessing at least some of this kind of translation is already done even on amd64 in order to support bounds checking from software.

Edit: disclaimer: I've never actually used it, just found it intensely interesting when it was first released. These days I tend to think of it as just another Google land-grab involving a non-portable API that backs onto some "trusted" service with only a single provider at present (kinda like App Engine). From reading the Chromium roadmap (they someday hope Chromium will itself mostly run underneath NaCl), seems that's very much what they want it to be in the long term.