I guess I mean poorly implemented not in the sense that they don't work (early 90's word is an engineering marvel) but the sense that in order to get them to work you are left with enormous amounts of baggage that will come back to haunt you in the future.
The 'classic' windowing toolkits and WYSIWYG implement the 2d portion of a 3d engine using a whole bunch of really cool hacks (necessary at the time) in order to run efficiently on a 286. Now days GPUs give us the luxury of not really having to worry about the cost of repainting the screen. The way QT, gtk, windows, etc. implement their interaction paradigms redraw/etc can all be subsumed by a 3d engine, and when it comes time to say, render a 3d graph inside of a hypertext document, then you don't face the huge abstraction impedance mismatch of having to drop into opengl because nothing else exits.
I'm not saying that you don't need the constructs that were developed to build the classic 2 interaction paradigms, in fact you will find most if not all of them recapitulated in every 3d engine. The point is that 3d engines are essentially the logical end of any input/rendering loop you can imagine and if you develop tools long enough the infrastructure and abstractions they provide will eventually be needed and if you were using a 3d engine from the start then you won't have to implement all that functionality from the beginning, usually without the benefits of decades of experience and tens of millions of users banging on your code.
To give a more concrete example -- think about how much it still sucks trying to get multimedia or good user interaction _inside_ of a word document. If word were implemented on top of a good 3d engine, then when you get the digital version of a paper the 2d projection graph is now suddenly trivial rendered because that is how it was created in the first place and the document format and editor have those capabilities from the start.
Somehow this reminds me of the first programming I ever really did in Squeak [0].
