The Chromium sandbox has three main components: seccomp-filters, namespaces and chroots.
Seccomp-filters are stackable and the syscall is not blocked by Flatpak’s seccomp-filter, thus the Seccomp-part of the Chromium sandboxes should stay intact.
The creation of namespaces and chroots gets blocked by Flatpak’s seccomp-filter. Then there is flatpak-spawn which can be used to further sandbox or even let processes run on the host.
Pls check the namespace structure of Flatpak’s Chromium vs the official native Chrome with lsns -T. You will see a noticable difference and weakened site isolation. The native Chrome namespace structure is more fine-grained. Thus leading to better horizontal isolation.
Browsers are very complicated and follow a clear security model, since they have to run (potentially malicious) untrusted code many times a day. No project just arbitrarily adds namespaces without a good security reason, because it adds quite some complexity.
So if you change the namespace structure, you should definitely have a very good reason and an exceptionally good understanding of the browsers security. If you change it, you need to proof that this makes things better, or at least not worse, and not the other way around.