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).
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.