- It is not clear yet which Xfce release will target a complete Xfce Wayland transition (or if such a transition will happen at all).
- We do not have the resources to maintain our own Wayland compositor
This should tell you everything. Since the Wayland ecosystem is extremely developer hostile it cements the KDE/GNOME duopoly and eliminates the long tail. XFCE might maybe make the push to Wayland but after that that's it. The rest of the tail is dead.
It's usually a lot easier to make a compositor/WM with unusual or innovative behavior on the Wayland stack than it was with X11 in general, as far less behavior is presumed/baked-into either the display server or the existing applications. For example, apps not being able to introspect or manipulate their global coordinates also means the compositor can arrange them however it wants without breaking app assumptions, which enables fancy new layouts.
There's prominent libraries that make compositor development easier, for example wlroots and QtWayland -- XFCE is also using wlroots. "Punt it to a library" isn't radically different from "punt it to Xorg", even if the slicing is a little different.
The tail looks alive and well.
That's a reasonable expectation, but it turns out the slicing does matter. For example: With Xorg, setxkbmap will always work to change the keyboard layout on the fly. Now, wlroots does support configuring the keyboard layout, but it turns out the compositor has to actually hook that functionality up, so if I try out a new compositor that looks neat, I can quickly discover that there's actually literally no way to change the keyboard layout because the developer hasn't gotten around to adding that yet. This is not a hypothetical example.
Now get off my lawn.