• 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.
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.