The sandboxing is almost always better because it’s an extra layer.
Even if you gain root inside the container, you’re not necessarily even root on the host. So you have to exploit some software that has a known vulnerable library, trigger that in that single application that uses this particular library version, root or escape the container, and then root the host too.
The most likely outcome is it messes up your home folder and anything your user have access to, but more likely less.
Also, something with a known vulnerability doesn’t mean it’s triggerable. If you use say, a zip library and only use it to decompress your own assets, then it doesn’t matter what bugs it has, it will only ever decompress that one known good zip file. It’s only a problem if untrusted files gets involved that you can trick the user in causing them to be opened and trigger the exploit.
It’s not ideal to have outdated dependencies, but the sandboxing helps a lot, and the fact only a few apps have known vulnerable libraries further reduces the attack surface. You start having to chain a lot of exploits to do anything meaningful, and at that point you target those kind of efforts to bigger more valuable targets.
Those kinds of problems aren’t particularly new (PGP comes to mind as an example back when you couldn’t export it out of the US), but it’s a reminder that a lot of open-source comes from the US and Europe and is subject to western nation’s will. The US is also apparently thinks China is “stealing” RISC-V.
To me that goes against the spirit of open-source, where where you come from and who you are shouldn’t matter, because the code is by the people for the people and no money is exchanged. It’s already out there in the open, it’s not like it will stop the enemy from using the code. What’s also silly about this is if the those people were contributing anonymously under a fake or generic name, nothing would have happened.
The Internet got ruined when Facebook normalized/enforced using your real identity online.