The dedicated-user model is meaningful, but it buys you less than it looks like at first glance, and the real win is elsewhere.

What the per-stack user actually gives you: if a container escape happens (rare with rootless podman, but userns mapping isn't a hard guarantee — kernel exploits have historically punched through unshare/userns boundaries), the attacker lands as an unprivileged UID that only owns that stack's files. So blast radius = one stack's data, not your whole home dir. That's the whole point, and it holds.

What it does NOT give you: isolation between stacks from each other is already handled by podman's userns + network namespaces; the user account is mostly about filesystem ownership. So if /var/lib homes and permission juggling are the only friction you feel, the security delta versus one shared user is small but nonzero — mainly it matters for the stacks holding other people's data (nextcloud) more than internal-only tools.

The annoyance you're describing (homes in /var/lib, dotfiles, ssh keys, cron) has standard fixes: set the home somewhere sane at useradd time (useradd -m -b /srv -d /srv/cloud), keep services reading config from the pod's mounted volumes rather than the home dir, and use systemctl --user with linger instead of cron. Most of the pain is a one-time setup cost, not recurring.

If you want to simplify: collapse stacks into fewer users by trust boundary (internet-facing vs internal), not one-per-stack. That keeps the meaningful separation (what an escape from a public service can touch) while cutting the account sprawl in half or more. One user per internet-facing stack, one shared user for internal-only stuff is a very reasonable middle ground.