I think many people in this thread are missing the fundamental reason that UDMF will completely obsolete the original format for new maps.
Within ZDoom, randy and Graf can add as many features to vertices, linedefs, sidedefs, sectors and things as they want. They can increase the storage space within the EXE indefinitely, meaning if there's call for a new thing flag, or new line flag, they can add it. Whether that means increasing the storage capacity of a single member variable or adding an entirely new one, not a problem. The bottleneck comes in the outdated mapping format that has been in use since Doom 1.666's release. The map format is strict, defining a certain amount of space for data to be stored for each feature. It cannot be expanded, so up until now if the developers wanted to add a new line flag, they had to create a new line special to indirectly set that flag at run-time. Now it's as easy as adding support in the EXE and expanding the UDMF format (which is infinitely expandable) to support a new entry for that flag.
Naturally this also means existing features are more directly-accessible. You no longer have to use a line special just to make a line translucent; just set it in the line's properties directly. And future features will be made much more convenient since they won't bother to support the line special method. The developers will simply add them as a new UDMF property. Of course this also means that the old binary format will become more and more obsolete as such features are added, but that's progress.
So, from a developer perspective, UDMF allows much more freedom and ease of coding when adding new features and supporting old ones. From a mapping perspective, it allows you to use existing features more easily and provides support for new features that mappers wouldn't have been able to use with the old format. For players, they will largely benefit from the new features that will be added because of UDMF's expandability. So, the short answer might be "Right now it doesn't do much different" but going down the road I think you'll quickly find out why the developers made the push to start supporting it.
Now, I have a question on custom properties being entered for these structures. CodeImp, you mention that DB2 allows a user to specify their own property freely, and certainly the UDMF format allows this (it is part of the format that the EXE ignore any property it doesn't recognize), but I can see that as trouble going down the road if the developers want to add a new property tag and some mapper has already used it in their custom map. Shouldn't there be a convention established for custom namespaces so this doesn't happen?