Naming frames is the biggest thing for me, and "just in time" frame generation. I don't like to name frames unless something external to my addon needs to get it's handle. Even then, I prefer to attach it to my addon's object instead.
XML was slower/used more memory in the past. Its faster now. It also does not need to be as verbose as blizzard tends to write it
Although it appears in their Schema, they never used <RelDimension> tags, and I suspect it didn't work. They changed the schema around 2.0 to allow tags to directly have the dimension as parameters. Since then, they have been converting the existing XML documents as they modify them to use the new format.
As I've heard and read everywhere, Kompozer (a derivative of Nvu) produces relatively "clean" code. Relatively being a keyword of course. No WYSIWYG-editor of any language will ever produce as optimized code as a veteran programmer will. But it CAN save tons of time of efficiency isn't top priority.
Let it not be mistaken. I abhor and detest the use of Word as a webpage editor. I admit to having used it when I was young and gullible (haven't we all in one form or another?), but today It'd have to be at gunpoint before I go down that road again.
I've been hand coding all my html for years, and I feel the same way as Phanx... I've run into a lot of stuff that other people did in WYSIWYGs. DreamWeaver (under certain circumstances) has the possibility of generating fairly clean code, but that is quite variable. It's still way better than MS Word's idea of HTML.
There are two places where I will often give in and use a WYSIWYG: MS Visual Studio (for Windows forms design) and NetBeans (when building Forms-based Java applications). In both those cases, I often find that I do the basic design with the WYSIWYG, but I still usually end up hand-tweaking a lot of little things before I'm done.
So far, the only WOW GUI I've done at all has been using AceConfig-3.0 and the AddToBlizOptions stuff to build a really nice set of menus into the Blizzard default Addon Config section. (Oh, and I've used the UIErrorFrame a couple times for quick alerts.)
If there was a decent visual tool for the XML frames, I might be tempted to play with it to generate some GUI, but I'd end up hand-coding more and more of it till I was only using the editor to view how my hand-coded stuff was looking outside of the WOW interface.
Actually, that's the tool I'd really like: A WOW client simulator that would let me see how my GUI would look without having to load the game. I can often steal a few minutes around lunch time to poke at code, but with all the dry-coding I have to do, I'm always afraid to make too many changes when I'm not able to change/test/fix/test/fix/PROFIT :)
I'm surprised nobody mentioned the separation of code and data in the XML vs Lua debate. I like to keep my frames out of my code, which is why I like to create frames in XML, even though I sometimes create a few low-level frames programmatically. As mentioned above a WYSIWYG is not a necessity (I don't use any, notepad++ ftw), what matters for me is the ability to see my frames in a clean hierarchy (code folding helps a lot).
About the wow client simulator, I'm behind DigitalSorceress on this one, I'd love to see that :)