The Windows kernel does offer an impressive number of options to lock down processes. Look at the Chrome sandbox code some time. The Windows API is huge but you can really lock it down a lot. The macOS sandbox architecture is, however, the best. The Linux approach is sadly in third place.
• Copy an EXE to %TEMP% and run it from there.
• Use a Win32 API flag to start a process (of any path) outside the app container.
There are only a few cases where Helium is an issue and they're all easy to work around. One example is writing a log file to your app private UserData directory and then opening Notepad on it. If you do it the 'naive' way then Notepad won't be able to find it, because you'll pass a redirected path which it can't see. The fix is simply to resolve the redirect before passing the argument to Notepad using a Win32 API call.
I know we talked about Conveyor a few days ago so I'll note here that if you package a JVM app with it then the %LOCALAPPDATA% and %APPDATA% environment variables are rewritten to their target locations automatically, so as long as you use them to decide where to write app private files then their paths will be visible to other apps, avoiding the Notepad issue. This doesn't apply to native or Electron apps though, at least not at this time.
Aren't those still user-based? So, in the typical case of a single-user computer, a rogue app that I run with my account would be able to access my data.
There's the protected folders thing (not sure about the name) since a few versions ago, which attempts to block random apps from accessing random folders.
But it's opt-in (folders are not protected by default, you have to add them one by one). It's also all or nothing: either a given app is "untrusted" and it can't access any of the protected folders, or it's "trusted" and it can access all of them.
I can't say I trust Photoshop to only touch my pictures folder, but not my .ssh folder.