I do understand that it may not be for everyone but my understanding is that when people say a desktop is not user focused, what they really mean is it isn't focused to people resistant to changes
That, or "it's not aligned perfectly with all my personal needs"
As an example, I feel like the usability of GNOME apps with client-side decorations is a lot poorer than the previous more traditional paradigms. The older paradigm may not be flawless, but it was much more consistent across applications, and most importantly, it's very easy to figure out. Trying to figure out how to do things in GNOME applications these days can be an exercise in frustration. I don't really want to play a game where I try to figure out what the trendy way to access the Settings dialog for a program is. Is it going to be somewhere in the global menu bar, or is it going to be on some nondescript button with dots or lines in it, or maybe something even MORE exciting? In the past, the worst thing was having to look through some defacto standard menus to find it. With modern applications, who knows.
Meanwhile, Mutter feels like it is resistant to practical concerns: they dug their heels on on server-side decorations, which did exactly what anyone could've told them it was going to do; now a bunch of applications have no or horribly broken borders on GNOME. I mean look, I know "it's really the application's fault because we said they had to deal with this" but also, I hope everyone understands that it genuinely doesn't matter, the outcome was predetermined based on the input.
On that front, I have a laundry list of complaints over how the direction Wayland has taken in GNOME in general, especially pushing things to clunky and unusable DBus interfaces that don't cover all of the important and already-common desktop use cases well enough. While I understand some of the reasoning, it is extremely difficult to argue that this isn't a focus on developer ideals over what would be ideal for users. Arguing that it's not "waylandy" to have input emulation in the Wayland protocol thus forcing you to use another binary protocol that's similar to Wayland but that you need to negotiate over DBus using desktop portals seems like a step very far in a weird direction when you are literally already speaking to the same compositor that's responsible for _dispatching_ input events.
Old man yells at cloud, but yeah GNOME definitely is "my way or the highway" in every regard, absolutely not a bastion of user-centric design or architecture. And that can be good if that's what you want, but I have a feeling it would be easily displaced by something that had a better attitude toward user concerns and pain points.
Even if KDE is buggy, it's extremely hard to argue it's not more user-centric. I'm wholly unsurprised when I see something like XWaylandVideoBridge coming out of KDE, as it's born out of trying to make things work for users rather than drawing a hardline.
That said, I do personally think GNOME and GTK4 are far better on phones and tablets than desktops. It's funny, because I simply would not consider them good options for desktop applications, but it all makes a lot more sense when you try it with a touchscreen. (That said, I don't view this as much of a saving grace because I've come to the conclusion that convergence is mostly a lie, something that you think is a good idea but in reality it's not; you just get something that's mostly bad on desktop, mostly bad on phone/tablet, or just generally not good on anything. GNOME is closer, IMO, to "mostly bad on desktop.")
Even if Gnome/GTK-4 supported server side decorations the problem of the heterogeneous app ecosystem would not be solved and you can observe the same regardless of the DE or even OS.
As a user the only major complaint I would have about Gnome is the regular breakage of extensions. On most distros it isn't an issue but it makes it rather unsuited to rolling release distros unless user is willing to regularly play with his package management config to prevent updates. On my Fedora machines it is not a big deal as the gnome major version is only upgraded on major Fedora version so I usually test with a VM before hand and if there is an extensions I really want to have I'll fix it o just wait a few weeks or months for the extension to be updated (or a fork being made).
serverside decorations are generally a broken paradigm too, pretty much no other system than X11 does them, and they introduce limitations and inconsistency to the application UI (the application can't reasonably control their contents so they're there to provide 3 buttons and waste a bunch of space), having integrated clientside decorations is one of the more visible reasons why gnome's UI feels polished and consistent
if the application is incapable of drawing reasonable decorations on its own, there is now libdecor (e.g. SDL uses it) and it has gained a gtk backend a while back, so it should be able to draw native decorations; while applications using a full toolkit have no problem in the first place, because the toolkits are fully capable of it
> lack of server-side decorations in mutter is primarily a technical problem that's not really easily solvable - currently the compositor code does not actually depend on any drawing library, to draw native serverside decorations it'd have to pull in entire gtk (a lot of effort was put into eliminating gtk from the wayland compositor path in the first place; mutter the X11 window manager, i.e. what xwayland applications use, has the dependency, so it can draw decorations)
Application developers and users don't care about Mutter's clean dependencies. It doesn't matter how the problem is solved, it just matters that it is solved. For all the application developers care, they can resolve the problem by having another process manage GTK shells around applications and not having Mutter actually do it.
As for not wanting GTK in Mutter, well, a lot of applications also don't want to have GTK in their process space, so it seems like this desire shouldn't be very surprising to GNOME developers.
What will happen here is that libdecor will be treated like a polyfill just for the snowflake case of GNOME and the damn-near rest of the world will figure out a way to do SSD. Exactly how doesn't matter, so as long as it's out of the application's own concerns. This is basically the only way that things can work, because if you wanted e.g. native titlebar regardless of whether you were on GNOME or KDE or something else entirely, you don't want to have every single flatpak/snap/whatever needing to pull in the entirety of GTK4 and Qt6 or whatever just to be able to try to have native titlebars. The only reason this works for GNOME is that GNOME is the only DE that does things that only work if they are the center of the universe, so you can have the GNOME case and the rest of the world case just fine. (I know the common argument here is "but what about Weston", but I am not aware of any desktop Linux system that boots into Weston, so it's really neither here nor there.)