Why not nspluginwrapper?

nspluginwrapper is not a sandboxing mechanism
An NPAPI plugin relies on unrestricted access to the underlying operating system, so a general plugin cannot be easily sandboxed. nspluginwrapper will only push the plug-in into a separate process; the child process itself is still fully priviledged.
nspluginwrapper is not a generic out-of-process plugin framework
While nspluginwrapper does push plugins out-of-process, modern browsers like Mozilla Firefox and Google Chrome natively support out-of-process plugins and, by doing so at the browser level, can do a better job.

It is not recommended to use nspluginwrapper for plugins which already run natively out-of-process in a modern browser. They should still work, but it only adds overhead.

Why nspluginwrapper?

nspluginwrapper is currently the only means to run a plugin in a browser of a different architecture. It is most commonly used to run a 32-bit plugin built for x86 in a 64-bit browser built for x86-64, but other combinations are possible with QEMU. While there is no reason browsers could not better solve this with existing out-of-process plugin, they currently do not. nspluginwrapper is developed primarily with filling this use case in mind.

nspluginwrapper also makes a good tracing utility for NPAPI plugins.