To me, at least, xfwm4's window management behavior is a big part of what makes Xfce... well, Xfce. So no, I don't think I'd consider using someone else's compositor.
To add a bit, hours later: I've been testing my Wayland support for the other components using Wayfire and Labwc, and honestly I find their window management incredibly frustrating. Part of it is just lack of familiarity, I'm sure, but honestly I just don't like how they do things.
A lot of xfwm4's behavior is windowing-independent, or fairly easy to put the windowing-specific calls behind interfaces. There's some of it that turns out to be pretty hard to untangle, which is where the real work is, but I think it's worthwhile work to take on.
Sure, the xfwm4 behaviour is absolutely something you'd need to be able to own in a technical and organisation sense. However all the other stuff around building a Wayland compositor is... big. Sharing portals, XWayland support, high dpi and mixed low/high dpi, display management as a whole, and that's just the stuff I know about..
I love xfce, I don't use it anymore though because I wanted Wayland support. As a (past and potentially future) user, I want to see a healthy xfce, not one that is burning out its devs with the giant task of maintaining a Wayland compositor. :)
Yes, I'm well aware it's big. I've already written some toy compositors to play around with, and have even written an embedded compositor library.
But it's worth doing here. And wlroots does so much heavy lifting that it becomes a lot more manageable. Most of the code in xfwm4 will still be window management code, as it should be.
I've worked on Xfce on and off for 20 years (mostly off, I suppose; probably a total of ~7 years in that time), so I get what these big things are like, and what maintainership means. We're also a very small team of volunteers who have other jobs and other things going on in our lives. But that's fine; Xfce does just fine with that level of work, and will continue to do just fine.