Not sure what you mean; wlroots still assumes that the window manager and compositor is in the same process. Wayland itself assumes that those things are also in the same process as the display protocol/server.
With X11, if someone wanted to write a window manager, they could do that and only that, without having to write a compositor or display server. Wlroots certainly simplifies those latter two bits, but there's still a lot of work to do to use it.
Beyond that, Wayland's mess of extension protocols are generally incomplete. I've been working on "porting" parts of Xfce to Wayland, and there are a significant number of things that just cannot be done at all right now without integrating it directly into the compositor process. The extension protocols necessary to do even a fraction of this table-stakes stuff are often experimental or non-standard, and even when they do exist, are often missing critical pieces.
As an example: say you want to write a dock-type app that only shows the list of toplevel windows present on the current workspace (and when you switch workspaces, it'll show the windows on the new workspace). Nope, you can't do it. The workspace protocol itself has been languishing in Freedesktop GitLab[0] for two and a half years, and even if that was standardized, it doesn't interact with the Foreign Toplevel protocol at all, so you have no idea what windows are on which workspaces.
So currently the only solution is: your dock app has to live in the same process as the compositor, where it has access to all the compositor-specific data around workspaces and windows. (Sure, you could build a d-bus interface, or something like that, but that would be specific to your one compositor... and a d-bus interface is the moral equivalent of a Wayland protocol, which is what you should be using anyway.)
[0] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...