Having unprivileged user namespace available from a process’ point of view is a security risk. This way it can spawn a new user namespace and use a “fake” root user inside this namespace, which maps to a non-root user outside of this namespace.
Now you might ask, what is the problem, if this only maps to a non-root user outside the namespace. Well, it exposes much larger kernel attack surface inside this namespace, which usually would not be available to an unprivileged user and could be used for privilege escalation, if an attacker has an exploit for this additionally exposed attack surface.
This is the reason why the vast majority of sandboxes block namespace creation via seccomp filter. Even popular container solutions like Docker have a default seccomp filter which blocks namespace from a container point of view.
It also means that using nested sandboxes based on namespaces is not an optimal solution, since you can only block namespace creation within the most inner namespace.
Android, which is way more security focused than Linux desktop OSes, doesn’t even enable user namespaces in the kernel and uses other means for sandboxing (unix users, selinux and seccomp filters). Secureblue uses Selinux to block user namespaces globally and has domains available which allow unprivileged user namespaces for some applications which actually profit from user namespaces, like Trivalent.
Seccomp filters stack in a way, that you can only decrease attack surface, but not increase.