The Gimp has been 'transitioning to GEGL' for how many years now? Something like six or seven years. And getting the data structures in place is only part of the challenge. How fast is this going to be for users? If the speed is to slow for users to efficiently get there work done at an intuitive pace then you have still failed.
From the initial GEGL integration attempts I saw the whole thing was hacked together with no clear thought to performance. And the performance was indeed quite abysmal.
There are very few sustainable free/open source projects, which have corporate or some other kind of backing - GNOME (redhat), Linux (linux foundation) and Blender (blender institute) are the only one that come to my mind.
It would be unreasonable to expect from unpaid volunteers if they has no ambition to do such work. Which is why I suggest that if you want to see advanced features and professional quality graphics software with a predictable cycle of development then you support the projects that actually try to create such programs.
Krita has a regular development cycle, a clear set of priorities and goals and funded development efforts that clearly lays out what features and improvement are going to be achieved with your hard earned money.
That has been an ENORMOUSLY successful improvement for both the programmers who can now get paid to work on there projects and the artists that now get quality continuously updated graphics software.
If Gimp or any other project deserve funding they have to step up and show the discipline and commitment to there project that successful projects like Krita have. I do not see that at this time so my recommendation is to support the projects that I listed in the OP.
> edit
As far as performance is concerned OpenCL or Cuda is not going to save you if your cpu bound memory architecture is not carefully thought for performance. This has always been a major problem for gimp for a long time. The higher bit depth and resolutions that are used now only exacerbate the situation. A general use case now could easily have tens of gigabytes worth of data that the user wants to manipulate delete and expand in real time. I have never seen this addressed in a serious proposal.
btw: I do love Krita, and I'm not saying they deserve any less support in favor of GIMP, but Krita is a lousy choice for certain image-editing routines where GIMP excels. Krita much more tailored towards artists, and I'd rather it stay that way.
The project has /always/ been unfriendly and abrasive. There's a reason why there aren't many contributors--the core team drove most of them away. I was a contributor in the early 2000s as a maintainer of the Print plugin (now gutenprint). I distanced myself from contributing because it was so painful and unpleasant. Same for GTK+. I went and worked on other stuff.
The other reason is technical. Why is the transition taking so long? Because the codebase is written in GObject-based C, and writing and refactoring this stuff is a nightmare. This also puts of a lot of potential contributors, and for good reason. Were it written in C++ or something else more amenable to ongoing maintenance and refactoring, it would have been possible to get this done much more quickly, and it would also have a vastly lower barrier to entry for potential contributors.
Moving to Qt is definitely possible; I've done it for other GTK+ projects. It can even be done incrementally; you could move the whole lot to use GTKmm widget by widget, and then once it's all C++ you can start the move to another toolkit. I'm not saying this because of any sort of Qt vs GTK+ zealotry, but rather because GObject-based C is inappropriate for sizeable codebases; the ability to maintain and refactor and contribute to a codebase matters, and this impedes all of them. Looking at the glacial progress of GIMP and other big GTK+ applications, as well as the bugs it causes, demonstrates this repeatedly. Plenty of other projects made the move and didn't look back, because once done it's vastly more productive to work with a C++ codebase, and with a significant increase in code quality. It's not 1997 any more.
