The idea behind OOUIs is to leave as much of the UI creation as possible to Kits on the server side and so to reduce the static information (shipped with the application) to the minimum.
This gives the most flexibilty to adapt to the user's environment (e.g. computing platform) and preferences.
To make as less assumptions about the UI implementation as possible, the description of the UI is very abstract (from the application's point of view). The description is mostly semantical, because this provides the necessary level of abstraction. Many ideas from object-orientation are used.
This level of abstraction gives the possibility to create very different, unforseeable UIs from the description.
Moving nearly all of the UI out of the application (modularity) gives the user
E.g. if a user likes the way, the GIMP arranges its windows, he can make all applications behave that way; if he prefers console programs, he just has to switch kits; if he has a true 3D environment, he again just has to get new kits; if he has only his cell phone available, he can still use the same application. Now, that's “portable” :).
Because the concrete UIs for all applications are created by the same entity, the OOUI kit, a high level of consistency is reached.
XXX rephrase Once the programmer knows, how to create OOUIs, the use of them should shorten app dev time, even if only one platform is targetted, because there is no need to care about UI implementation details. However, this is just a positive side-effect, not a goal.
A comfortable filemanager similar to Microsoft Windows Explorer could be created in one day. An example diagram has been developed in 2 hours. When the simple backend code using OS commands is written, the filemanager is finished.