Another thing to look at is bubblewrap (https://github.com/containers/bubblewrap), which is what implements the sandboxing in Flatpak. It's handy if you want to run a command from your host in a particular sandbox as kind of a one-off, or if you just want to understand more about how that sandboxing works :)
But doesn't flatpack offer much deeper system Integration by default? Like being able to access the home directory by default and being able to talk to dbus?
To me flatpack looks like a way achieve application compatibility not security
I think this depends on your use case. As a dev I would take dockerized gui applications over flatpak all day, as it allows me to quickly add additional packages and networking for example. The possibilities would be endless while all can reside in a small docker-compose stack right in the repository.
Your perspective is understandable. When you say "as a dev" it sounds like you really want to be a docker dev but not a flatpak dev: you are used to writing docker files and docker-compose files but you are not interested in writing flatpak apps. That's okay because docker is focused on developers whereas flatpak is more user-centric.
I am not (only) a docker dev but a developer using docker tooling for my development environment. Feature wise docker and flatpak are not even comparable IMO. Just wanted to make a point, why flatpak is not (yet) an option for some people, and projects like this are very welcome.
You can always build your own flatpak image with whatever else you need. I think the only thing you're losing is the layered architecture of OSI images.
This is a nicely written description of some of the things that flatpak does under the hood for people who know docker. Of course, flatpak does a lot more (e.g. filtered dbus access).
I personally think that flatpak is not the end of history and we should continue to experiment with different approaches.
