This is interesting, but I wouldn't consider this to be at all comparable to Flatpak. From what I can see the only purpose of using bubblewrap here is the dependency isolation (without having to recompile the world ala Nix), which does have some value but it feels misleading to even call it a sandbox.
It mounts /home and /run into the ~~sandbox~~ chroot, which means that "sandboxed" applications can do things like reading your SSH keys, dumping your keyring or escaping the sandbox via write to .bashrc (so most of the attacks you'd want to prevent). This is presumably done because without /home access you wouldn't be able to write to the filesystem and without /run access you can't even display a graphical window, which would make the packages quite useless.
XDG Desktop Portal solves this by allowing filtered dbus access controlled by package metadata (/.flatpak-info), and then having sandboxed applications use portals to access files, secrets and other resources. The metadata is a major flaw in Flatpaks design (note that a lot of the most popular Flatpaks want full $HOME access), but it's also what allows Flatpak to be useful. In this project, there's no metadata since the packages just come from Alpine repositories.