No application is forced to adhere to these recommendations (even by participating in the discussion); rather the hope is that collaboration will engender solutions beneficial to all.
The shared resources spec, for instance, calls for graphics apps to store all brushes, patterns, gradients, and color swatches under a shared directory. In the current draft this is called the art-supplies directory -- system wide at /usr/share/art-supplies/ and ~/.art-supplies/ on a per-user basis -- though the name is still up for debate.
This idea is useful to both users and developers. For example, the GIMP, Cinepaint, and Krita all use the same brush format. Each available brush is a raster image in grayscale or RGB color. Many ship with the programs, and users can create their own either from scratch or by modifying existing brushes. They are tiny files, but there is no reason for keeping three copies of each one, and end users will appreciate not having to recreate custom brush sizes in all three applications.
Furthermore, the hypothetical kid in his basement writing tomorrow's wildly successful new graphics application can code to the spec and have one less thing to worry about. Or, should some commercial vendor port their application to Linux, there will be a readymade answer to the question "how do they do this on Linux?"
A more controversial front is user interaction. Almost all media applications use some manner of zoom commands, but the keyboard shortcuts vary wildly from program to program.
The question is, if such shortcuts were the same across the applications, would usability increase? On one hand, you would not have to pause and think when switching from one application to another. On the other, the zoom commands can do very different things in unrelated applications. Take "Zoom to 100%" for instance; in a raster graphics program this usually interpreted as one-pixel-per-dot-on-the-screen, but in a vector graphics program it usually means zoom-to-print-size.
Clearly, there are no easy answers. The Create project founders know this, and are quite open about their intentions: collaborate and discuss the issues, not rule on them. The specifications mentioned above are under constant revision; this is a project that lives and breathes on its mailing list and wiki, not its downloads page.
If you are interested in participating, read through the draft specifications, join the mailing list, and talk.
It's no secret that bundling moves products: Microsoft bundles Office, Adobe bundles Creative Suite, Apple bundles iLife. Software bundles appeal to buyers in terms of price ("sure, it's slightly more than I wanted, but I get more for my money") but also in terms of integration ("if I get all of these together, at least I can be sure that they'll work right").
For free software, then, integration is the challenge. As yet no one is bundling open source graphics and multimedia software in direct competition to Creative Suite or iLife. Perhaps this effort will bring that day closer, but the benefits of integration are good for today, too.