Wayland is a complicated and sore topic for a lot of people, but I think I've gained some perspective over time.

From a historical perspective, the "why Wayland?" question is incredibly obvious IMO. The old Linux graphics stack consisted of the dumb Linux framebuffer and fbcon, and the separate Xorg stack with all its DDX/UMS drivers that required root-level permissions, and only provided a graphics API for ... Xorg. Your options were either Xorg, or the framebuffer, which IIRC didn't always support all of the available display modes.

Wayland was part of a wider push to rewrite the Linux graphics stack, with the new stack of KMS/DRM/DRI3/Mesa being a huge improvement over the 2000s Linux GUI stack. This came at the cost of old UMS and DRI drivers, making e.g. PowerPC Mac GPUs largely useless now (very unstable and incapable of suspend-to-RAM), while unifying mode-setting between the kernel and userland (no more praying the video card doesn't crash when ctrl-alt-f2'ing), also allowing for an arbitrary number of shared video buffers to be created (including by non GLX video applications) which makes compositors work in a not-hacked-together sense, but also allows for e.g. hardware video decoders to work in a not-hacky way.

Coupled with the addition of evdev to replace the Xorg DDX stuff like all the custom peripheral drivers, and you finally had a kernel-level API for accessing your video and input hardware. These were all prerequisites for the idea of "Wayland", decoupling the video and input layers from the display server and creating a low level API for window server things, so that you can have both small window servers (e.g. wlroots-based compositors) as well as "thick" environments (Mutter/KWin-based desktops).

Part of what makes this confusing is a lot of these benefits trickled down to Xorg itself. Nowadays evdev (and libinput) have replaced the old DDXs on Xorg, and I think most distros have switched to using xf86-video-modesetting, which could be thought of as "Wayland-style rendering on Xorg", in the sense it uses pure DRM and Mesa to render instead of GPU-specific DDX drivers.

So Xorg has gotten a lot of the benefits of Wayland's development "for free" anyway. This is intentional, as you mention, a lot of things will never be ported to Wayland. Wayland is not a replacement for X11, but an API for implementing the display server at a lower level than X11 allowed, while allowing us to implement full X11 compatibility "for free", by embedding Xorg in the form of Xwayland.

I think this makes a ton of sense for the majority of desktop-environment level compositors like Mutter (GNOME) and KWin (Plasma), which were already massive and implemented so much of their own functionality outside of Xorg, that it made sense to just let them do their own compositing. Same with GTK and Qt, which were already doing "their own rendering" outside of X.

Didn't mean for this to become an apologetic rant for Wayland, but as a "wayland skeptic" myself I feel like most anti-wayland arguments miss the forest for the trees (screen sharing not working). As an olive branch, though, I'll also add I don't think the wayland version of the big compositors like Mutter or KWin actually do much for end users, and it's pretty shameful how they've been launched with so many bugs, with no compelling user story beyond "better scaling" and "flicker".