Carbon just worked, and was usable as fundament for long term libraries and frameworks. Even Adobe postponed the migration several times ( and eventually went with a cloud version)
More true than you think. Adobe were probably still sore about having to move from 68k to PPC! Plus, the whole "Apple killed my Flash Player!" thing probably didn't help much.
I'm more talking about the 2003-2010 era, and then specially the (somewhat sure) rumour that there was a 64-bit Carbon but only for Adobe, not for users.
I did poke around in the LCL, but it doesn't have what I need. My GUI is fully drawn with my own widgets and interface. I need to open a window, draw on it and catch mouse and keyboard action and that's about it. My Windows and Cocoa classes are only about 250 lines each, so should be quick work to translate over, although I'm going to do the full package rather than the "only what I need" version that I have now.
If it is that small, I'd not bother with LCL either.
All of the 2D drawing packages I've seen either rely on Carbon (extinct about now) or OpenGL (gently being shoved out the door by Metal as we speak.). What most people don't realize is that Cocoa and GDI are very highly optimized by their OSes and are extremely fast.
Since Vista the drawing speeds of various operations change with GDI, and since the desktop became compositing, doublebuffering is often less needed.
However extremely fast is IMHO too much honor. I don't know COCOA, Metal and its progression good enough to judge performance.
I used Apple's for private work as *nix workstations up to 2005 partially because OS X was one of the first systems that got hibernation right, then with another architecture change and constant API breakage I gave up. And I'm glad I did when I see what followed. If app binaries can't be used for extended periods of time, for me there was little added value to e.g. BSD or Linux, which have the same problem. And Windows got hibernation reasonably right.
I just removed all my GUI drawing optimizations as they were slowing things down compared to just redrawing the whole window everything. I don't see either APIs going anywhere anytime soon. I was working on an OpenGL version of my GUI and when I got it running, it wasn't any faster since I still had to do the drawing in the cpu! (NanoVG, if memory serves.)
Opengl is an art. Exact performance is card (+driver) dependent. But probably for normal windowing operations and control it doesn't matter.
I use opengl at work for "live" images of a vision system, and it is very fast specially on Intel APUs of generation 4000 and later (because GPU upload is suddenly magnitudes faster than with older or PCIexpress cards). Uploading, drawing (scaled) large images (e.g. 28MB) and drawing 130.000 objects on top in the 0.1-1ms total range.