Beyond the "this is too hard" responses (which from personal experience working on GUIs and toolkits for decades i think are overblown), it is also that a GUI toolkit -or any other library really- written in a niche language will only be usable for that niche language's audience but a GUI toolkit -or any other library- written in a language that can be used by other languages with almost zero friction, is way more likely to be used.
And people tend to use what they see other people using, thus repeating the cycle.
So you see these 15 year old libraries being used because other people are using these 15 year old libraries because they are written in languages that can be (relatively) easily be wrapped (both C and C++ wrapping can be done automatically and there are many tools for that - largely because this is something a ton of people want to do, so again, it feeds back to the cycle of things being popular because they are popular).
But there are lots of new toolkits being made, you can even find a submission for a new one in Hacker News almost every month (though the responses are pretty much the same in all of them :-P).
Also note that Qt, while having a legacy of its prior versions, has seen significant investments keep it up to date. You aren't using an "old" library, you are using a modern library in its latest incarnation.
Assuming you are talking about Qt/wxWidgets, and I don't think they are easy to create bindings for due to being written in C++. I think they have been used because they represent the largest, most complete crossplatform codebases representing the traditional desktop GUI using either native widgets, or in Qt's case "simulated" native looking widgets.
In contrast, GTK is written in C AFAIK, and anytime a new language springs up the very first thing you generally see is a GTK wrapper. I have always suspected this is because C is far easier to wrap since most languages have a well defined C FFI, but typically lack a C++ one (due to lack of std ABI) thus Qt/wxWidgets bindings typically lag GTK.
C is also a relatively simple procedural language which constrains the APIs that e.g. GTK can offer. This makes working with GTK in its native platform uglier than Qt, but does mean alternative bindings can build their own more ergonomic abstractions on top of it.
Qt on the other hand is very much a C++ OOP style, so if there's an impedance mismatch representing that in your language, as is the case for Rust, C or Go, then it gets much harder to do. The C++ bindings do present difficulty of course, but you can see from e.g. PyQT that if the pattern works in your language it's one that can be overcome.
And there are other choices Qt makes that are unfriendly for, say, Rust too, QString is defined in terms of UTF-16 code units, which was probably a pragmatic choice when Qt was younger, but inconvenient today since of course Rust can't necessarily be confident this is actually Unicode (I tried but was unsuccessful in figuring out what CXX-Qt does about that) and on non-Windows systems Rust doesn't have a built-in representation for this "a bunch of UTF-16 code units" pseudo string, yet on Windows you probably do want that structure because it is what other Windows stuff expects such as the File APIs...
This a good point, and I agree that C++ made sense at the time as it is much richer for creating a GUI. I've never tried to use GTK C GObject interface, but I've seen some snippets and it looked nasty to me. However, in hindsight, it at least makes it fairly easy to create bindings for and I suspect many (most?) don't use the GTK C API but some other language bindings, so it turned out to make a lot of sense I think.
There are tools to create bindings for C and C++, like SWIG you can see some examples in [0], e.g. the wxWidgets bindings for Python. AFAIK for Gtk bindings can be generated using gobject introspection handling most (if not all) of the mundane bits.
I'm aware and have used SWIG. It is amazing, but a) it doesn't support all languages b) it still takes a lot of work to create C++ bindings. This is primarily due to the complexity of C++ APIs vs. relative simplicity of a C-based API as another poster commented, not any shortcoming of SWIG.
So yes, there are tools, my point is it is still much easier to wrap a C based API because you can often just use your language FFI, not an external toolset.
Sure, i do not disagree that wrapping C++ is harder than C, but my point was that the language is widespread and popular enough to actually have tools that assist such wrappings, unlike other languages, so even if all else were equal you are more likely to see a C or C++ library be wrapped than -say- a Free Pascal library (which can create DLL/so/etc that are 100% compatible with C and thus wrappable).
They can be among the harder parts of a toolkit (though it also depends on the toolkit's scope - can't really compare something like Qt that has a very large scope going even outside GUIs with something like imgui, which only provides the most barebones GUI functionality) yes, but i think the "hardness" exists not in how hard they are to have that functionality but in most people not even thinking about these things.
And people tend to use what they see other people using, thus repeating the cycle.
So you see these 15 year old libraries being used because other people are using these 15 year old libraries because they are written in languages that can be (relatively) easily be wrapped (both C and C++ wrapping can be done automatically and there are many tools for that - largely because this is something a ton of people want to do, so again, it feeds back to the cycle of things being popular because they are popular).
But there are lots of new toolkits being made, you can even find a submission for a new one in Hacker News almost every month (though the responses are pretty much the same in all of them :-P).