Without snap, the front door is wide open: all applications you run are unconfined within your user account and can snoop on all of your files. On a normal single-user desktop system, almost everything valuable is within your user account, not root. If an attacker does want root (such as to install a rootkit that can hide itself or to access other user accounts), they can install an alias to sudo on your account and piggy-back on the next time you use it.

I think a better question is whether there are simpler approaches to sandboxing applications that avoid this problem by design.

The answer is definitely "yes". Many articles and books have been written about UNIX administration, and separating accounts, even without jails.

With jails, you could do even better.

Well yeah, if everything runs unsandboxed as root then there are no privilege escalations!

Less pithy, i seem to recall many issue with programs that relied on suid and permission dropping, which would be the 'oldschool' way of firming up the above.

You're not wrong that complexity has been introduced, and I'm not a a fan of snap either, but ultimately sandboxes (esp backwards compatible ones that don't need source level modifications) are complex.

If you want simple and secure, you're probably looking at OpenBSD and pledge.

This isn't really systemd's fault at all. Systemd just happens to be what cleans up /tmp. You would have the same problem with tmpreaper.

The problem is snapd not protecting against something else writing to /tmp.

Permission and timing gotchas in /tmp predate snap and systemd. It's why things like `mkstemp` exist.

I remember cron jobs that did what systemd-tmpfiles-clean does before it existed. All unix daemons using /tmp run the risk of misusing /tmp. I don't know snap well enough to say anything about it makes it uniquely more susceptible to that.