I'm well aware. We've also sent spacecraft to Mars. Porting a large codebase from one UI toolkit to another, all the while giving up hard-earned knowledge in a volunteer-driven project is still a super daunting task.
I'd argue that this depends a lot how the code is structured. Back in the day of Win32 and MFC it was not unusual at all to very tightly integrate logic and the UI, often even outsourcing parts of state machines to GUI controls etc.; such a code base is difficult to port to anything. If, on the other hand, the application is written in a more layered approach, then porting from one toolkit to another may mean to just re-engineer the UI and only the UI. Complex custom controls mentioned by Raphael below are another factor.
It's a graphic design program. If there is a project where tight integration between the graphic library and the rest of the codebase is expected (for performance reasons) and hard to avoid is here.
In wireshark, for example, its meat is in the networking code, and the important skills of the developers are there, on inkscape, on the other side, the non-trivial contributions probably happen very near to the graphic frontend. If GTK goes to the gutter, retraining the developers to get to the same level in Qt will set Inkscape back years.
There have been a lot of major projects ported to Qt over the years, both commercial and open source (e.g. Wireshark, Subsurface).