There's absolutely zero reason for bc(1) to accept network connections, or for grep(1) to execve(2) into arbitrary programs. But both of these programs need to process and interpret arbitrary input, which makes them potential targets for exploits.
You don't technically "need" security, just like you don't "need" seatbelts... until you actually are in an accident.
https://man.openbsd.org/pledge; https://man.openbsd.org/unveil
Flatpack's are for packaged software-deployment, those are two different things.
Why the need for a sandbox if you could do it much cleaner with things like pledge? But in typical linux fashion, just put another layer on top the pile of garbage so it stop's to stink for a while.
>Well - why would I not want that?
Then please start with the most obvious application sometimes called kernel.
Instead of rigorously integrate something like SElinux they throw layers over layers of half-backed "sandboxes", up to the point to separate applications with Xen (Qube-os), then you find out about Meltdown, and we are back in 1990.
My point is, containerisation on Linux isn't necessarily slow—in fact it's unnoticeable if implemented correctly—and I prefer to default to having a decent amount of security by containerising as much software as I can, whatever the origin. Including, and especially software like the calculator, since it should not be able to do anything more than show a GUI and add numbers together.
Without flatpak I'd need to use some rolling release distribution, where not just a few applications get updated quickly, but also the rest of the system, which I'm not interested in.