Previously, on Linux, your desktop environment is made out of:
The display server (xorg), in charge of dealing with the video card (by talking with drivers in the kernel through a unified interface, DRI), and handling how to display stuff properly on your particular combination of hardware, including your physical screen and its peculiarities.
A window manager, in charge of asking software for what they want to draw, then drawing windows, decorating them, etc. and more generally organizing what will be displayed on the screen and how it will be displayed.
A protocol allowing both to communicate between each other.
That protocol is old, shitty, and insecure. Those are rightful criticisms of it, and it could be argued there is a need for an alternative. This is the often touted justification for wayland.
Note that the way windows and the general desktop environment is handled in the model above is completely distinct from the actual display server; this has a nice advantage: one can write a WM relatively easily, and as such there are hundreds available for linux users to choose from - including some that traditional Windows and Mac users would consider visually exotic and different, such as tiling WMs. This has long been considered a distinct superiority of Linux over, for example, Windows, where all of this is a monolithic block.
Now the dudes that introduced wayland didn't just decide to secure the protocol; they decided to do away with that separation. Now a "compositor" handles all the stuff both xorg and the WM used to do. This means that almost none of the existing window managers work on this thing (actually the truth is none of them do, but Gnome and a few others for example created whole new compositors - today, you can run "gnome" either with that shit or with Xorg, for example), and that there will be far less of them to pick from in the future. The people implementing wayland didn't even consider this an issue at first (everyone uses gnome or KDE, right ? imbeciles), so IIRC third party devs eventually tried to implement a library to restore some degree of separation (wlroots). This still requires reimplementing a WM though, and ultimately is extremely limited anyway due to the very "security" concepts the wayland protocol introduces. Some stuff that was trivial on Xorg will not be possible at all.
You might be considering why we're talking about security in the context of a display server.
Well, the Wayland people noticed that more and more, people were installing software on Linux not through the official repositories of their distributions (which are high quality, somewhat audited, etc.) but from a galaxy of alternatives proposed by a variety of actors: flatpak, AppImage, snap, etc. The reason for this is the quality of software in general has taken a dive, and so has the quality of developers in the open source community; the usual process for someone wanting to be published on, say, debian, would normally have been to follow a few simple rules and to publish your package, accepting it'll be audited and you may have a few points to work on before it'll get up on the repos. Many devs these days are not interested, and deploy their software through the alternatives I mentioned above (which are basically all container or chroot based approaches to produce a "minisystem" with a set of defined libraries, meaning only your kernel will differ from the person having published that package).
As a result, a lot of clueless people are now installing shady software like monkeys on their system, coming from anywhere, just like on Windows. As such, the Wayland creators consider stuff such as an application discreetly capable of capturing the screen, or copying the clipboard from another app, to be potential "security issues". You may be interested to now such "security measures" do not exist on, for example, Windows (but the "security issue" do).
I'm not even trying to argue whether or not they're wrong here. I think mostly they are - the amount of issues and use cases they didn't consider is incredibly large, and it's been biting them in the ass ever since - but it's irrelevant; in theory this would not be much of a problem because, you can just keep using Xorg and your WM, right ? the fear is that maintainers and support for these will dry up (I doubt that, personally), but also and more cruciallly that as Wayland becomes more and more omnipresent for many users, various features from various critical software - such as the browser - will eventually become problematic for Xorg users.
Previously, on Linux, your desktop environment is made out of:
That protocol is old, shitty, and insecure. Those are rightful criticisms of it, and it could be argued there is a need for an alternative. This is the often touted justification for wayland.
Note that the way windows and the general desktop environment is handled in the model above is completely distinct from the actual display server; this has a nice advantage: one can write a WM relatively easily, and as such there are hundreds available for linux users to choose from - including some that traditional Windows and Mac users would consider visually exotic and different, such as tiling WMs. This has long been considered a distinct superiority of Linux over, for example, Windows, where all of this is a monolithic block.
Now the dudes that introduced wayland didn't just decide to secure the protocol; they decided to do away with that separation. Now a "compositor" handles all the stuff both xorg and the WM used to do. This means that almost none of the existing window managers work on this thing (actually the truth is none of them do, but Gnome and a few others for example created whole new compositors - today, you can run "gnome" either with that shit or with Xorg, for example), and that there will be far less of them to pick from in the future. The people implementing wayland didn't even consider this an issue at first (everyone uses gnome or KDE, right ? imbeciles), so IIRC third party devs eventually tried to implement a library to restore some degree of separation (wlroots). This still requires reimplementing a WM though, and ultimately is extremely limited anyway due to the very "security" concepts the wayland protocol introduces. Some stuff that was trivial on Xorg will not be possible at all.
You might be considering why we're talking about security in the context of a display server.
Well, the Wayland people noticed that more and more, people were installing software on Linux not through the official repositories of their distributions (which are high quality, somewhat audited, etc.) but from a galaxy of alternatives proposed by a variety of actors: flatpak, AppImage, snap, etc. The reason for this is the quality of software in general has taken a dive, and so has the quality of developers in the open source community; the usual process for someone wanting to be published on, say, debian, would normally have been to follow a few simple rules and to publish your package, accepting it'll be audited and you may have a few points to work on before it'll get up on the repos. Many devs these days are not interested, and deploy their software through the alternatives I mentioned above (which are basically all container or chroot based approaches to produce a "minisystem" with a set of defined libraries, meaning only your kernel will differ from the person having published that package).
As a result, a lot of clueless people are now installing shady software like monkeys on their system, coming from anywhere, just like on Windows. As such, the Wayland creators consider stuff such as an application discreetly capable of capturing the screen, or copying the clipboard from another app, to be potential "security issues". You may be interested to now such "security measures" do not exist on, for example, Windows (but the "security issue" do).
I'm not even trying to argue whether or not they're wrong here. I think mostly they are - the amount of issues and use cases they didn't consider is incredibly large, and it's been biting them in the ass ever since - but it's irrelevant; in theory this would not be much of a problem because, you can just keep using Xorg and your WM, right ? the fear is that maintainers and support for these will dry up (I doubt that, personally), but also and more cruciallly that as Wayland becomes more and more omnipresent for many users, various features from various critical software - such as the browser - will eventually become problematic for Xorg users.