Woah, no. Sure escaping via a kernel bug or some issue in the container runtime is unexpected, but I "escape" containers all the time in my job because of configuration issues, poorly considered bind mounts, or the "contained" service itself ends up being designed to manage some things outside of the container.

Might be valid to not consider it with the services you run, but that reasoning is very wrong.

I guess I should define my threat model first. Your answer pulls me towards a single user though

Companies don't typically host multiple containers on the same host. So having a different user for them is less important than securing the connection between machines, since a given biat isn't particularly interesting. Attackers will still try to break out, so they have a backup.

As a self-hoster, you typically do the opposite. You run multiple services on the same host, and the internal network isn't particularly secure. So you should be focusing more on mitigating issues, and having each service run as an unprivileged user is one fairly easy way to do that.