I like that take on boring tech, and a little like Oracle, I don't think X is boring. Wayland definitely isn't either, but I think it has potential.
Late in the sense that OS X has had Quartz from the beginning, and Vista started the move to DWM; meanwhile the Linux community was patting itself on the back because Compiz looked cooler than either of those, and didn't see past the surface. X11 is not only an outdated design, it's also a security nightmare.
Early because it's still a mixed bag, and kinda suffers from second system. It's a protocol rather than a library - while it's simpler than X11, it relies heavily on optional extensions for things such as screen capture or even "server" side decorations. Under X11, you could write a spartan-but-functional WM in a 100 lines of C. Under Wayland, a functional compositor needs roughly 50k lines; wlroots can handle most of that, but neither KDE or Gnome uses it, so effectively there's three parallel worlds, with varying level of support for different extensions. Early on, IMHO too much effort went into Weston (the "reference" implementation nobody cares about), and too little into building something like wlroots. It may take a while for the situation to settle.
Whilst I agree with most your point, you're comparing a window manager and a compositor. I don't think there was any compositor for X that was made with less than 100 lines of C.
Which is my point. A project like wlroots should have been in the spotlight the same way Xorg was, so that new compositors (or existing X11 WMs) could adopt it easily, and both users and developers could benefit from an emerging-but-stable ecosystem. Instead it took like a decade to standardise and implement screen capture.
Because compositors had graphic pipelines and could add those with OpenGL shaders. But, there's still much more to a compositor, namely they actually composite the windows/screen, rendering things into GL textures and intercepting the rendering pipeline in X, ensuring everything is synced to avoid tearing etc. This is their main purpose.
Wayland is just an API that lets clients talk to the compositor direct rather than having to go through the X server.
So even a "trivial" compositor like xcompmgr, that runs alongside a WM, has to do all of this dance? The WM still has the authority to tell X, "draw this window here", but X lets xcompmgr take the wheel? (I can tell from here why X was already becoming more of a drag.)
Wayland (as an API) was designed to solve, which is why in theory it's supposed to have better performance, latency and power efficiency, although it hasn't worked out great in all cases.