Please don't use this type of hyperbole, I've heard this type of thing often in various contexts, and while it may be fun to say, it's inaccurate and it's thoroughly unproductive in getting the actual issues solved. What you view as incompetence and disregard is more accurately described as "lack of time." IIRC there are only really 2-3 people working full time on GTK, and most of their efforts are focused on getting new releases out the door. It's not as many resources as it may seem from the outside and they don't have time to do everything that people want. They depend on volunteer contributors to handle the long tail of issues and edge cases that come up with older applications.

If you'd like to improve GTK2 and GTK1 applications, please find a way to contribute and help out! I can help to point you in a direction if you want. (I don't think it's really much of a big deal if older applications look weird, the main concern with them is usually that they don't break. From this angle, GTK1 and GTK2 apps are not being left behind, they work perfectly fine even on a modern system) I'll warn you though, it's not trivial to get a legacy app to look and act native on a modern platform. If you really want to do a good job at it, you have to manually redesign each of the apps individually and it gets time-consuming.

I personally think it would be great if XFCE/Mate/Budgie/Cinnamon/etc had the resources to pay more full time developers to contribute upstream and collaborate more with the GNOME people, but we are not there yet unfortunately.

>Expecting that it is something that "shouldn't hold up a GTK release" is a completely wrong way of thinking about backwards compatibility

Why? Once you decide to refactor an API you have to maintain an extra piece to translate the old to the new, there is no way around that. Developers can spend time before the release working on this translation piece alongside the new features or they can just release it now so people can test the new API before deciding to invest in developing that. For an open source project I can't see how the first option really makes sense, and if your argument is that they should have been developing it the whole time, that is essentially what they were doing for the entirety of the GTK3 development cycle.

That is being generous in assuming that it's even possible to do this, sometimes a design is so flawed that you can't even make it work at all with the new stuff. At some point you have decide to cut deprecated APIs or you are left with an infinitely growing pile of technical debt. I referred to this elsewhere, but old GTK1/2 applications that use raw unscaled pixel buffers are an example: there is no backwards compatibility that is going to work here that makes them function correctly with high dpi. It simply cannot work if the application is hardcoded to use an old API that has no concept of dpi or scale and assumes a pixel is always the same size. (Maybe someone can cheat with AI upscaling algorithms but those are usually pretty slow :)

I guess to put it another way: I don't see any way that GTK4 could have been designed differently to do something like make it easier to compile GTK1 apps against it while reaping all the benefits of GTK4. If somebody wants to make a GTK1 shim for GTK4 that translates GTK1 API calls into GTK4 API calls, they can go do it now, it would probably be a pain and it's probably not going to magically get you all the new benefits that would come from just porting the application to GTK4 and refactoring to use its new techniques along the way.