The issue with CPX size wasn't really so much the overhead of a high-level language. It was the fact that they were all individually compiled and linked as stand-alone things. Meaning if you had a half-dozen CPX modules loading, you likely had half a dozen copies of the same C runtime code.
Beyond that, the real problem is something I've touched on in my blog... the way GEM AES was designed, your application had to do a fair amount of work just to do the "basic" minimum level of event handling for the GUI. So, in addition to that half dozen copies of the same C runtime code, you probably also had a half dozen copies of essentially the same code for processing messages, redraw events, etc.
Neither of those issues really has anything to do with "C" being inefficient or not. It wouldn't have been that hard to do a shared runtime library that only needed to be loaded once. And because of the differences in how the system has default behaviours for event handling, an executable for a simple program similar to a CPX might only be a kilobyte or two for MS Windows, versus probably at least 10-12kb with GEM.
Dozens of C overhead is still C overhead . Better said overhead of overhead
I don't think that APPs need to do so much work for some simple dialog, window and like. In case of my disk imaging and copy SW, what is about 10 KB long, only about 1.5 KB is code for init AES, draw dialog, handle user inputs etc. RSC is much longer - some 3 KB. Other is disk code self. So. I don't think that we need some special library for that - although I use always same code for AES and VDI calls, but that's really short - not more than 300 bytes.
Certainly can do some ACC or CPX module like for setting 16 colors in 2-3 KB size - including simple dialog.