I’m sorry, I may not have the time to answer every point you have made:

> I was not convinced that there was anything inherently wrong with X11-the-protocol

There is, the non-existant security model that can’t really be backfitted without breaking every program - in which case they can just as well fix all the bad parts.

> Is there a particular point in the video you want me to pay extra attention to that clarifies this?

I found the graphics of the client-compositor-Xserver vs client-compisitor under Wayland really informative. In modern usage, the Xserver actually acts more like a library and IPC bus, and is bad at the latter. Also, related to the API thing, there is no way to signal that a buffer is ready. You may not be interested in the “every frame is perfect”, but I like that I can watch a video in vlc without tearing.
Also, a wayland compositor can be much more lightweight than the whole xserver, because it is not as chatty (there is no useless communication to the xserver that communicates to the compositor for no reason)
It’s not without reason that wayland is/can be used in embedded systems.

> and did not see anything related to controlling which programs get to see which events

There is a one-to-one communication with the compositor and the client. Keyboard events, window resize and the like are sent to only a specific client. I may have worded it incorrectly that it is specified — I would rather say it has an inherent model for it, that can be changed with extension protocols when needed. But the default should not have been the everyone listens to everything and find what is interesting. (For example it is now possible that a global hotkey have to be registered and the compisitor will react to that based on the registration. But there can’t be a clash now and it will work reliably)
Also, in my opinion this flexibility (with which clients should not worry about) lets you create novel ways to interact with windows, that was not possible with X.

Also, you seem to think that there is all that much difference between compositor families —- it is not the case. The core and many extension libraries are while implemented multiple times, work in the same way. Thus a traditional client with some windows will just work. Some compositor have some custom extension for eg. having a specific status bar, which you may find bad since under X there could be cross-wm status bars etc. But realistically you could not have them eg. under gnome or kde without tinkering, so the status quo doesn’t really change.

> Also, putting core functionality that everyone must implement the same way into extensions just so they can call Wayland "just a protocol" or "just a display manager" is disingenuous

How would you create that API of X you mentionod? Wayland is a protocol, the core is mandatory. And it is in a repo, so that it can have versions — this is yet again an area where x is flawed. Even the core api can continue to evolve, and eg the compositor/client can both decide to support for example an older version — although in practise the core api is backward compatible. But a new feature for example can be used by a fresh client when available, with a proper way to fallback — due to the wl_registry.

> Does the wlroots project define what extensions are standard and required for a piece of software to call itself a Wayland compositor

That is the core protocol. You seem to have a misunderstanding around it. Otherwise, how would a wayland app work on every wayland compisitor? Wlroots can have some custom extensions and it does have , but you seem to misunderstand the point of those/scope of them. They are simple things like “a specific window that can work as a widget, eg don’t loose focus etc”.
Everything buffer related is core, and for example full screen WAS not part of the core initially, but an implementation that all compositors agreed on was merged and everyone implemented it many years ago.

> If you can't help me understand why Wayland could not have been implemented as an X extension

I’m trying to but you seem to have some grudge against the project.
I am no X developer so unfortunately I don’t have more knowledge on the topic than what I have already shared, but for example X developers tried to retrofit HiDPI to X, and things like mixed HiDPI over multiple monitors (hell, the whole multi-screen setup) simply can’t be done realistically — from what I gathered due to X API’s lack of semantic informations like scale. Wayland corrected the many many failings of the API in a future proof way that can avoid. Also, why do you think that basically every OS already changed to a compositor-based display server 2 decades ago? It is simply the better abstraction and this is a simple answer, but it is the fundamental one.