In a traditional app packaged as a deb/rpm the developer releases the source which then must be packaged and made to work with each distribution/platform. If the app is malicious or is sold to someone/compromised by someone who is then you are 100% hosed.
In a flatpak not designed to be properly sandboxed you are in fact no worse off than the alternative deb/rpm situation save that the issue of packing for distribution has been made easier.
It's in fact probably extremely challenging to package all sorts of applications without giving the user the option to provide an individual app elevated permissions.
At best we are relying on the user to decide which app ought to get those permissions.
If you think people can't be trusted to do this then the logical solution is to rely on packagers to decide what belongs in the official repo and keep malicious content out.
In the meantime – sure, package the app, but it shouldn’t show up as “sandboxed” in the GUI if the sandbox isn’t meaningful. Instead it should come with a nice scary warning that the app has access to all of your files… you know, for everyone to ignore and click through. (You can lead a horse to water…)
If an app doesn't get an security fix whoever maintains that package should be the one to blame.
Disclaimer: I don't like flatpak either, I'm just trying to be fair here...
There's nothing about the idea of a sandbox that requires a specific approach.
Then how do you get it to operate on your actual home directory when you want it to? Making it operate on some different structure has been possible with chroot() or LVM snapshots or a number of other things for a long time.
There are many more applications, not just IDEs, where picking a file or folder is not sufficient: for example, apps like Rapid Photo Downloader or Darktable would be significantly crippled.
