Flatpak itself is really a different dimension of security to that discussed here. It solves a different problem (the software might have exploitable security vulnerabilities) than the one discussed here (the software itself might be malicious). Running software that secretly phones home everything you do in the program is still going to be a problem in flatpak.
I wouldn't say that it's a different dimension. If you install a Flatpak (and you check that the permissions it asks for make sense), the application will not be able to do as much damage even if it's malicious.
Furthermore I'd argue that a big reason (2) > (1) is not that Google/Apple are that great at detecting malicious applications, but that malicious applications also have a harder time getting too many permissions with their system.
And furthermore, a reason why "curl | bash" is bad, is that you are piping arbitrary code straight into a shell, which gives no chance for the system to know which permissions the code needs. Whereas if you do a "curl ... && flatpak install ...", it can.
This argument is moot once you allow said software to have access to your files...which you will usually have to if you want that software to be useful to you.
Access scoped to a directory is a big improvement over an unsandboxed process. Any unprivileged program can trivially steal your browser sessions by reading your profile dir, but with Flatpak it would be possible to only grant it access to your "documents". I don't know if this is currently done in practice though, or if it's still common to just grant it full access to ~, including dotfiles. Even if so, the technology is there, showing a clear route to improvement