Sure, I may have used stronger language than necessary because I do feel strongly for the issue as I am really fond of the kernel and many of the excellent work of the ecosystem. What I meant under “comfortable to use” is that a sandbox needs to communicate with the sandboxed application and with the general system to be truly usable. Otherwise it is more like a firewall for syscalls. Which has its place and is good for an absolute boundary, but it is not a UX for end users. If I use a bad firefox profile in firejail it should not just crash, firefox should be told what’s the situation. The most basic example would probably be a file chooser dialog — the application should be able to call for such a dialog but the dialog is made by the OS and only the selected file should be made available to the sandboxed program. Flatpak’s portals are a good direction, but I’m not sure that it is a good implementation.
I also have to agree with you on the “one can make it secure” part, e.g. android builds on top of pretty standard linux tools to achieve its better security, namely selinux for a larger boundary and the most important: running different processes as different users! It is such a gaping security issue in typical DEs, as otherwise not even the very crude UNIX permission system can do anything meaningful (other than the relevant xckcd comic: the attacker can access all my files, my browser cache, etc, but at least can’t install a video driver)