With Blender's UI it was designed as a modeling software for a small studio, in house, with the developers working directly with the artists that used the software professionally.
As a result it's like the Vi of 3D modelers. It's extremely fast with a bit of a esoteric interface. (different though that it's extremely non-modular.. this was a design goal.)
Not 'fast' as in processing speed, but 'fast' in your ability to crank models out. For cranking out 3D models there is very few applications that can keep up with a experienced Blender user.
The problem with Blender is that it's not just a modeler. It's a entire product suite with integrated renderer, texture editor, animation, composition engine, game engine etc etc.
The stuff that was made AFTER it was open sourced, and all the non-modular stuff generally sucked. Especially UI-wised. It did not provide the functionality that artists need, nor did it provide the existing functionality in a way that was accessible to artists.
With those projects they went back to having the developers working with artists in professional-like settings. They were then much better able to identify missing functionality, poor functionality, and identify areas in the UI that needed improvement. As a result a lot of the animation suite and game engine was completely overhauled. The UI changes and new functionality is what makes up the major reason for the Blender 2.5 release.
Human communication is extremely difficult and if your going to depend on just mailing lists and bug reports then it's going to be extremely difficult to write good software for other people.
Linux has benefited heavily from the fact that it was written by developers for developers. The 'by hackers for hackers' type thing. When you have a close tie between yourself and your users then that allows you to really get done what is needed to get done. There is a lot of poor UI theory and guesswork, but every application is different, and every group of users are different. Unless your able to work directly with them and observe people using your software in a real world environment _during_development_ then it's going to put the developers at a real disadvantage.
How many times have Gimp developers had a chance to sit down and observe professionals using their software and interacted with them while this was happening? Users know what they need and what they want, but they are going to be very ill-equipped to actually communicate this with programmers. Users generally will do a poor job guessing on what they need to say to programmers in order to get what they want. Programmers will tend to focus on things they need and things that fascinates them or holds their attention.
Working closely with users and observing them work is something that Adobe would do with Photoshop on a regular basis...