A few reasons user namespaces don't fully replace setuid here:

First, snap-confine has to set up mount namespaces and apply AppArmor profiles before exec'ing the actual snap payload. Some of those mounts (particularly bind-mounting the snap's squashfs under /snap) require real CAP_SYS_ADMIN, not the fake version you get inside a user namespace. User namespaces give you apparent root within the container, but kernel operations that affect the host mount namespace still need real privileges.

Second, and more fundamentally: Snap explicitly supports snaps that run as actual root on the host. System daemon snaps (snapd itself, kernel snaps, gadget snaps on Ubuntu Core) need to perform privileged operations that cannot be faked with user namespaces: loading kernel modules, configuring network interfaces at the host level, writing to block devices. For those, you need the real thing.

The curt15 reply has it right — user namespaces can't satisfy the contract for snaps that legitimately need host-level root. The unfortunate consequence is that snap-confine has to be setuid root, which gives it one of the most dangerous privilege levels a userspace binary can have, which is exactly why vulnerabilities in it are so serious.

Snap supports programs running as real root. Would those work with user namespaces?

There are several reasons but at some point we can use user namespaces to remove them. I'm not particularly a HN person so I won't go into details but it's possible to drop the setuid bits sooner rather than later.