I think that the earliest methods of programming windowed computers were just way over the heads of mere mortals, including myself. For those of us where were comfortable with earlier computers, GUI required simultaneously grasping OOP, a mountain of opaque documentation, and a complex IDE and build process. All at once.
No surprise that the first GUI programs I wrote were in LabVIEW and Hypercard, followed soon thereafter by VB.
While I'm not a commercial developer, I still avoid any "stack" where the tutorial for "Hello World" doesn't fit comfortably in one page.
Earliest practical GUIs were (Smalltalk aside) generally not OOP but rather procedural - an explicit message dispatch loop, message handlers that were basically huge switch statements etc. Here's the listing for a basic Win32 app (Win16 looked very similar):
OOP was bolted on later to make this all more manageable. Indeed, VB itself, which is object-oriented (even if it lacks some common features such as inheritance) is a prime example of that.
It's interesting that VB5 and 6 were what I call "object based." You could use pre-defined objects, but didn't have to create them yourself. In fact you needed some special "edition" to create objects, which I never did. But was a great way to ease a beginner into OOP -- by using them before creating them.
Now of course I'm not a beginner -- that can only happen once. And maybe it has gotten easier to learn. I remember the series in Byte Magazine about OOP, and it was just utterly baffling, but now I can't imagine why it seemed hard.
Meanwhile, I stepped off the software development bus, and so I don't care as much about "finished" software. Building crude GUI's in Tkinter is satisfactory for my needs these days.
It sounds like you're describing VB4 and below. In VB5+, the underlying object model was COM, and you absolutely could define and instantiate classes. Many built-in types for common operations also had to be instantiated - e.g. Collection, or anything to do with database access.
etc. Free Pascal also has this, slightly generalized now so you can use strings for IDs.
But FWIW I think most people who were writing those apps back in the day didn't think of it as OOP. It was more like, one day you learned about classes and objects, and then you realized that those things you've been writing were basically about that, but with a lot more manual scaffolding.
I guess another take on this is that OOP just flows naturally from GUI problems. To this day, I still remember my first TUI app, completely handcoded in Turbo BASIC. It had a bespoke event loop, and message dispatch, and widgets; but I didn't know about any of those things at the time - it just developed organically as I went about doing the thing that I wanted to do (in that case, a simple UI for a flat file database of sorts).
I was lucky to have learned multiple approaches to OOP, with TP 5.5 followed by TP 6.0 with Turbo Vision, as entry point into the world.
Eventually I came to grasp the concepts, the ways it was done different across languages, and came to the realisation a very bare bones description would be to say that an object is a module you can assign to variables. Which incidently is what you get in Standard ML with functors, with polymorphism for the dispatch.
Turbo Vision documentation, typing from head not going into bitsavers, actually had to guide people away from that approach you are describing to letting the framework handle those scenarios, even in MS-DOS.
Ah, Turbo BASIC, my first actual BASIC compiler, and entry into being a Borland products consumer.
GUIs are still harder than they need to be. Async patterns that don't compose, operating systems where CLI and GUI programs are separate concepts entirely, massively complex GPU-based stacks needed to fill 800 MP/s...
I no longer blame people for punting to Electron. As bad as HTML is, it's still only 100 MB to save yourself from the worst parts of GUIs.
Very slow release cycle and long lifetimes. Qt moves pretty quick and this causes problems for downstream projects. E.g. KDE had to keep Qt 5 alive for _years_ until KDE 6 was ready. Rochus Keller has a version of Qt 5 as well. Trinity is still maintaining Qt 3.
Extremely wide cross-platform support, e.g. on the BSDs and some other niche OSes. I think there's even a Haiku version.
No surprise that the first GUI programs I wrote were in LabVIEW and Hypercard, followed soon thereafter by VB.
While I'm not a commercial developer, I still avoid any "stack" where the tutorial for "Hello World" doesn't fit comfortably in one page.