I'm wondering how does this work in a world of plugins? (for example Windows/oSX world, where programs like Autodesk 3DSMax/Maya, Adobe Photoshop, etc. use plugins)?
The simplest case, which is still pretty useful, would be to just have each application require the superset of the syscall functionality any of its components (including any plugins) might require. That would result in fairly broad permissions needed for some apps, but in most cases probably still less than "everything". Plus you get a lot of low-hanging fruit closed off in the rest of the applications, which I think is the main target here: not to harden Photoshop, but to harden the many things in the base system that look more like file(1).
There have been actual exploits (multiple ones!) in file(1), where a bug in parsing can result in arbitrary code execution. That's really a failing of the permissions model: file(1) is a program that does nothing but read a file and print a result, so buggy parsing code should have a failure mode no worse than either it crashing, or printing the wrong result. But as-is, since it has the full permissions of the user who ran it, it can do things like email someone your SSH keys, or delete your home directory, which is functionality the binary clearly doesn't need access to for legitimate operation.
Applications that embed many utils into one almost always have a dispatch tree based on what they were called as and/or what their first argument is. In such an app, the app could figure out what job it's doing at the moment, and then call pledge() appropriately. Pledge() essentially says, "from this point forth, I pledge I will only need syscalls x, y, and z, so don't let me do anything else."
For plugins, that gets complicated. That's a case where there would need to be some reworking of how plugins are called, perhaps breaking the program into a series of plugins connected by pipes, where each individual program has its small set of abilities. But that's just an off the top of my head guess, there could very well be a better way of doing it.
It's not much different than seccomp/systrace/apparmor/grsec rbac/selinux in that regard. It's per process. So sure, if the plugin forks it could pledge(). Much the same way the plugin could seccomp once forked. Otherwise the plugins rules would be applied to the application.
All the same, even if the app used it with most syscalls enabled, it would reduce the attack surface.
There have been actual exploits (multiple ones!) in file(1), where a bug in parsing can result in arbitrary code execution. That's really a failing of the permissions model: file(1) is a program that does nothing but read a file and print a result, so buggy parsing code should have a failure mode no worse than either it crashing, or printing the wrong result. But as-is, since it has the full permissions of the user who ran it, it can do things like email someone your SSH keys, or delete your home directory, which is functionality the binary clearly doesn't need access to for legitimate operation.