Many of those work by running processes under what is effectively a subuser.
The problem with it is, that it works fine when one purely speak of being able to write and read from files, but the moment servers such as display servers or Pulsaudio and DBus come into play, the picture becomes more difficult.
All of those technologies work on a simple binary level where the subuser has access to the socket, or it does not, for finer grained control the kernel is required to speak the protocol, which will obviously not happen.
So, those services themselves must come with a means to filter communication appropriately, and sandboxing technology is beholden to the extent thereof.
Flatpak had to provide an alternative DBus-proxy server to do this with DBus, similar to using nested X11 servers; no solution has been reached for Pulseaudio, whereof I know, and no plans even exist for a variety of more obscure servers that software might need to communicate.
For instance, ZNC can be instructed from the IRC client to load modules that contain arbitrary code. Therefore, any IRC client that has acces to ZNC has ZNC's full capabilities, as it does not come with such finer granulation as of this moment.
If any sandboxing technology is to be effective, a large number of servers that are in common use often need to provide specific support for that specific sandboxing technology, or simply not be accessible at all from within it.