Are we in a state where GTK4 is the GNOME toolkit and non GNOME apps will be permanently stuck on GTK3?
To make matters worse, GTK4 "tightens up" some interfaces, making it harder to extend. So, for example, you can no longer "wrap" a native window handle on X11 with a GdkWindow (an interface that also no longer exists, in favor of a Wayland-centric GdkSurface interface) in order to integrate something "foreign" into the toolkit. They've also removed things like GtkSocket & GtkPlug, so you can't do cross-process embedding anymore[1].
I think it's fair to say, though that GTK4+libadwaita is "the GNOME toolkit", and GTK4 alone is just a much less capable, less extensible, less "batteries included" toolkit than GTK3, and GTK5 will drive even further in that direction, if GTK4's deprecation list is any indication.
[0] Full disclosure: I'm an Xfce developer, and have been disappointed with the direction GTK has been taking for some time. I don't begrudge them their prerogative to do what they need/want to achieve their own goals with the toolkit they've built and maintain. But it really is making life more difficult for me.
[1] Part of the argument is that Wayland doesn't natively support things like cross-process embedding, so a cross-platform toolkit shouldn't have these types of widgets (the classic problem of only being able to support the lowest common denominator). But a) you can absolutely build something like that for Wayland (something I've been working on, though it requires tens of thousands of lines of code to do), and b) with other changes, it's incredibly difficult and possibly impossible to even implement the XEMBED protocol on GTK4, for people who do only care about X11.
All Cinnamon, MATE, and XFCE need is a libxapp similar to libadwaita which provides the design language that is common between those desktop environments. No one seems to have started on it though.
Your example shows the opposite though. GtkSocket & GtkPlug were removed because they were buggy and never worked on any non-X11 platforms. Removing platform-specific hacks and moving towards standard interfaces is the correct way to go if you want a generic "batteries included" toolkit and not just something that can be used to hack things together on specific Unix platforms using a specific outdated window system.
I doubt anyone has any actual interest in making it work in GTK4 because XEmbed is a pretty broken concept full of race conditions that was never fully implemented anyway. And design-wise XEmbed doesn't actually make any sense because you need to funnel everything through the X server just for one app to host another one. The proper way to do it is to have the Socket be a server and make the Plug a client that talks directly to it through its own socket. I imagine your Wayland solution does this by running a small pass-through Wayland server. That should get easier over time as Wayland libraries improve, which I can't say about XEmbed because X11 isn't being developed anymore. Doing something like that is also AFAIK the only way it would work on MacOS.
Regardless, the GTK developers probably won't merge any replacement for Socket/Plug unless it works on all supported platforms including Windows and Mac, and it actually fixes all the bugs that were in XEmbed. And you have to ask the question: why is this needed anyway? In my experience this isn't a general-purpose feature, the huge majority of apps work better when whatever embedded widget is put in a shared library, or uses RPC (i.e. D-Bus) calls to populate its own in-process views.