DRI2 will be slightly slower, because it involves an extra step (drawing from the offscreen buffer to the screen).
However, unless there's something that needs to apply effects to the buffer, that shouldn't be necessary. Does anyone know if there's a mechanism for switching between direct-to-framebuffer and redirected rendering?
KDE does not have that problem.
DRI2 without compositing should be just as fast as DRI without compositing.
Fullscreen games should disable compositing while running to get the same performance under DRI2. I'm not sure how that works.
GTK+ uses a box model (similar in spirit to the HTML DOM). You tell the toolkit what the relationship between widgets are instead of giving it specific pixel positions. When a widget changes size, the toolkit recalculates all necessary layout information.
Qt is pretty much the same, as is the Firefox GUI (being derived from the DOM box model, that's not much of a surprise). I don't know about OpenOffice. Most other toolkits use a similar model.
Individual applications may have bugs, especially those using custom widgets or making heavy use of canvas widgets. I know Firefox had/has some bugs regarding the size of windows, as some of them (especially the Preferences window) behaved like the window size was set to a specific pixel size, and if the elements in the window become bigger, they'd no longer fit in the window. Hopefully the latest version resizes the window automatically to fit the window contents.
Most GUIs these days are designed with a box model approach, mostly due to the overwhelming number of designers and developers starting out with HTML/CSS and then moving on to native toolkits.