And on top of that the “security” is useless because any software that runs as one's user account can simply do things such as ptrace the compositor or override the compositor in the PATH with a malicious one or LD_PRELOAD the compositor. As soon as malicious software run as one's own user, then that is that and it can do anything that the user can do.
The argument raised against this is that it should be used in conjunction with some measure of a sandboxing technique, and that X11 is “impossible to sandbox”, but X11 sandboxes exist: how they work is a proxy server that sits in between the sandboxed application and the real server that determines what to let through and what not, the sandboxed application thus believes it is the only thing running inside of it's own X11 server, which maps it onto the bigger one.
Then the counter argument is that that “doesn't count” and isn't “true sandboxing”, but that is the exact same technique that sandboxes that use Wayland use for say DBus, or PulseAudio, and has always been the standard way of sandboxing such daemons and servers.
That's always the highly theoretical argument that comes in to defend these promises that are false on a practical level “it doesn't count”, even though the practical result is the same.
All the ways to circumvent Wayland's security “don't count” even though they can all the same be used to compromise it.
I am quite convinced after having spoken with many a Wayland developer that nigh none of them actually care about the “security” they so often talk about: they care about a certain theoretical elegance of a “secure system" that only exists in theory but exists in no reality as something that actually has been practically realized. All the actual, effective, real world ways to pierce it are wished away with that they “don't count” as they don't exist in their theoretical dream world.