I had been working both with NaCl and PNaCl back then, and truth be told, once Google made the switch from NaCl to PNaCl most advantages just disappeared. The compilation of the PNaCl bytecode on start (which was more or less just a subset of LLVM IR) took longer than even the first WASM implementations.
PNaCl definitely suffered hard from slow startup times because it ran LLVM for compilation from PNaCl bytecode to native code on startup, and LLVM is slow (I even noticed this compilation process on startup on my absolutely trivial test code). Only the predecessor NaCl didn't suffer from this problem.
There was no 'access to other native APIs', PNaCl created its own set of wrapper APIs to access browser features, and while some of those were better than their standardized web API counterparts, some NaCl/PNaCl APIs were worse than the web APIs they replaced - and for the future, PNaCl would have to create more non-standard APIs for every little feature available in browsers, because:
Integration with the webpage and Javascript was done via message passing, which was just terrible when compared to how easy and fast it is to call between WASM and JS.
The NaCl/PNaCl multithreading feature would have been hit just as hard by Spectre/Meltdown as the SharedArrayBuffer based threading in WASM.
Finally, when you look at the PNaCl toolchain versus Emscripten, Emscripten definitely comes out on top because Emscripten was much more concerned about integrating well with existing build systems and simplify porting of existing code, while NaCl/PNaCl had its own weird build system (in old Google NIH tradition). Working with NaCl/PNaCl felt more like working with the Android NDK, which is pretty much the worst developer experience in the world.
It's also worth noting that the NaCl and PNaCl teams were integrated into a large Wasm team at Google and brought their expertise to the project. While we didn't all 100% agree on every decision made in Wasm design, we were intimately familiar with the tradeoffs made by those prior projects.
Ultimately the sandboxing requirement of running in-process with the renderer process and integrating with Web APIs like JS dictated hard requirements for security.
PNaCl definitely suffered hard from slow startup times because it ran LLVM for compilation from PNaCl bytecode to native code on startup, and LLVM is slow (I even noticed this compilation process on startup on my absolutely trivial test code). Only the predecessor NaCl didn't suffer from this problem.
There was no 'access to other native APIs', PNaCl created its own set of wrapper APIs to access browser features, and while some of those were better than their standardized web API counterparts, some NaCl/PNaCl APIs were worse than the web APIs they replaced - and for the future, PNaCl would have to create more non-standard APIs for every little feature available in browsers, because:
Integration with the webpage and Javascript was done via message passing, which was just terrible when compared to how easy and fast it is to call between WASM and JS.
The NaCl/PNaCl multithreading feature would have been hit just as hard by Spectre/Meltdown as the SharedArrayBuffer based threading in WASM.
Finally, when you look at the PNaCl toolchain versus Emscripten, Emscripten definitely comes out on top because Emscripten was much more concerned about integrating well with existing build systems and simplify porting of existing code, while NaCl/PNaCl had its own weird build system (in old Google NIH tradition). Working with NaCl/PNaCl felt more like working with the Android NDK, which is pretty much the worst developer experience in the world.