The real reason would be that X contains lots and lots of cruft which isn't used anymore and it made development&testing impossible.
Follow along this post and you'll end up with one case in the wild all by yourself on your own machine: https://theinvisiblethings.blogspot.com/2011/04/linux-securi...
Xace was designed to address the mess that is Xsecurity and using the SELinux sandbox for GUI apps, except Xace barely works for mitigating exploits well on the desktop; it's so finicky that Dan Walsh himself concluded that XACE does not work and instead opted to use nested X servers (!!): http://people.fedoraproject.org/~dwalsh/SELinux/Presentation...
>Follow along this post and you'll end up with one case in the wild all by yourself on your own machine
I know it's possible. The 'case in the wild' terminology is asking whether this was ever weaponized in an exploit. I don't recall X ever being an attack vector in the last decade or two. I guess there are more than enough ways to gain local root this class of exploits doesn't matter.
Now, I'm all for closing this hole. But there's something bad about a development strategy that finds things like this and DPI with multiple monitors very important - the vast vast majority of users only have a single monitor - and mostly ignored scenarios like remote desktop until 2020 or so - remote desktop always used by several orders of magnitude more users than HiDPI, and a little tiny bit more important with this mass pandemic going on.
Maybe that's why transitioning from X to Wayland takes more time than transitioning from python2 to python3, a well known example of successful migration.
So the reason for not exploiting X may very well be simply because there is an even easier exploit available..
So, to be blunt, this 'security feature' breaks a whole hell of a lot of use cases. If wayland wished to go down this route they should have displayed a prompt to the end user 'this application wishes to record the screen, that ok?'. The last time I made this point someone snidely informed me that 'this was not wayland's responsibility'. I'm sorry, if you break my use case you make it your responsibility!
It is true that it isn't strictly the responsibility of the Wayland protocol, the API functionality is still there just it has moved somewhere else where it's more appropriate.