The developers makes every decision on how an application works and looks (It's part of the code). The top row of pixels is no different.
People don't have to explain their preferences in a rational way, they will just switch away from GTK3. It's cheaper.
Successful developers will try to interpret these users' feedback in a self-critical, introspective and positive way, and tweak their product based on the feedback. As opposed to continually challenging the giver of the feedback to explain their opinion in more detail, as if by repeatedly digging deeper and deeper into an opinion, you will at some point find some fundamental logical contradiction in their views that will make them re-evaluate their life philosophy on why they just don't like GTK3.
I for one think the two opinions given above are perfectly clear ("GTK3 is becoming very GNOME3 specific", "As a user, I don't want them") and can't see why further clarification is being requested. If you really need clarification on these perfectly clear opinions, it is your problem.
What I stated was that development decisions, whatever they are, are up to the developers, including which frameworks they wish to use, and how they wish to use them. Saying in any form that you don't want developers to make decisions is nonsensical, as they would not be able to write anything then. Decisions have to be made, compromises chosen, and ultimately, not everyone will get their will.
If you don't want other developers to make decisions for you, you're stuck writing all the software you want to use yourself.
I suspect this of being as recent an attitude as "no, it's fine that a desktop chat client should take up nearly 4 GB doing absolutely nothing, memory is made to be used".
There are enough of us who lived through the days when, no, developers didn't need to make certain decisions for us on the Linux desktop. It wasn't a perfect time but it did exist — as recently as ten years to fifteen years ago in the days of GTK+2 and KDE 3.
Again, it wasn't perfect, but those days contradict your assertion. People shouldn't have their opinions discounted because they're no longer in vogue.
I also don't really appreciate being called a "fanboy" by the GP. I use Qt as well and I don't favor any framework over another. I'm sticking to the facts here: GTK supports building apps any way you want, not just in the GNOME style. Maybe the problem is that the apps you tried happen to all be GNOME-styled apps. That's a choice that the app developers have to make consciously and has nothing to do with GTK. If there is something else you mean by "locked into GNOME" then please elaborate, because I am having trouble understanding what you're referring to.
If the user is able to spot the choice of toolkit just by using the application, I'd suspect that design decisions have been coupled to code decisions, which would be a smell by itself. I mean, what exactly would you do if the code guy says, GTK fits the code best, and the design guy says, Qt fits the design best? The answer would be "the Qt look-and-feel for design, and the GTK API for code", but you can't do that when you have coupled these decisions.
In Qt it's absolutely possible for applications to force client-side decorations and force a certain stylesheet. Maybe it's not common in the apps you use, but again, it's up to the app developer if they want to make use of those things or not.
They also break them at every release.
Regardless of that I don't see anything based on "cascading styles" as lending itself to a stable theming system anyway. The CSS is probably going to change any time a widget is added/refactored/bugfixed, this holds true on the web as well once you build up a complex library of React components or whatever. The point of it is that there are multiple styles from multiple sources that can cascade together. It's powerful but it can result in a lot of complexity, anyone who's had to add !important directives can attest to that. It needs to be strictly managed by the developers to really work correctly and to prevent the style overrides from getting out of hand. Allowing custom user CSS is only for power users who understand the caveats.
From the perspective of making design decisions, it's somewhat equivalent to swapping the phone shell on a Nokia 3310.
Applications run as part of a system that provides certain shared system-wide features and is configured by the user. They should slot into that system.
KIO vs GVFS? :)
Filesystem drivers are much further down the stack, but that's just a different group of developers making all the decisions.