There are 2 major technical issues with X which Wayland tries to solve.
First is security, which isn’t because of the ability to bring up X on a remote machine, it’s because X was designed before untrusted programs were even considered. The problem is that any program connected to an X server has basically total control over the X server. It can read the contents of other windows, it can read (or block, or simulate) user input. In fact, compositors for X only work by abusing this security issue, they are just regular X programs that decide to take charge of window positioning, user input, and so on. Under Wayland, user input goes directly to the compositor, which decides where to forward it, and windows can only see each other via a protocol extension (which, with all existing compositors, prompts the user for permission).
Second is performance. X started out not just as a windowing system, but also as a drawing system (think G/TK or QT). You can still use it as such. This means what is sent to X can be very low level (draw a box here, write this text there, and so on). Only problem is that requires blocking calls to the X server. For example, starting something like gedit under X requires somewhere around 80 blocking calls to the X server. This is why remote X sessions are so terribly slow with modern applications. Also, because X was the drawing toolkit, there is no notion of a frame, drawing calls begin immediately, so you can actually watch the text and buttons and so on appear in real-time on the display. Problem is when you are displaying video or playing a game (or scrolling a web page), the monitor will often end up ready for then next frame in the middle of the some program writing the next frame, and you get tearing. VSync tries to fix this, but causes additional input latency and is often imperfect (better recently, but still not perfect). The Wayland protocol introduces the concept of frames, so the client tells the compositor “it’s ready to draw”. Which fixes the tearing issue, even on rather poor hardware.
There are a few drawbacks. First is software support. GTK and QT, as well as firefox, support Wayland. SDL has wayland support, but lots of SDL apps get input directly from X, or call X-related functions directly. XWayland works about 90% of the time, even for games. It doesn’t support variable refresh rate, though there is a proposal for an extension for that. XWayland defaults to no remote permissions, not even for root (which is why synaptic fails). It’s also only in the last several months that things like OBS can be used under some Wayland compositors.
Note that critics of Wayland will say “it’s not network transparent”, which is a red herring. X isn’t network transparent either, there are several extensions which only work on the same machine. Yes, applications can run remotely, you can even use local video acceleration and display remotely, but the performance suffers. Meanwhile, you can do exactly the same thing under Wayland, via the Xwayland shim. You can also use compressing remote protocols (h264 encoded VNC for example). Also the wayland protocol can be relayed over the network with a relatively small shim on both ends. No one has bothered to write one since there isn’t actually much demand for remote applications like that anymore.
and a better UPS 
not going to risk losing my work due to a black-out or frying something because of a brown out … but lol Synatipc runs fine on an Intel Purism deblobbed CPU/iGPU