Maintaining a single code base is obviously convenient for developers. You might also argue that, since mobile devices are the most common computers today, their interfaces should be the standard.
However, what is convenient for developers doesn't always provide the best user experience. Transparencies and constant screen changes might be endurable on mobile devices -- although, even there, I doubt many people like them. But on laptops or workstations, these features only increase the number of mouse-clicks to perform a task.
The best solution I've seen to this problem is KDE's. In KDE, the interface is separated from the functionality, so designing for a different device is largely a matter of designing the interface. This arrangement, which has advanced with every release in the KDE 4 series, is not as convenient as a single code base. But it is nearly as convenient, and allows more flexibility than a single code base could ever possibly equal.
On any other operating system, configuration would be much less important. It might not even make this list. But Linux users are accustomed to doing things their way. They may not customize every available feature, but they appreciate having the option.
Look at the reactions to KDE 4.0, GNOME 3, or Unity, and by far the largest complaint is the loss of configurability. In comparison, I have yet to encounter anyone who complains about the controls that Linux Mint has added in its efforts to recreate GNOME 2 on top of GNOME 3. Linux users expect to be able to customize their desktops, and grow twitchy when they can't.
These rules are not all that is needed. At least some of the debate over the new interfaces could have been avoided by fully explaining the changes in public, rather than trying to launch an ad campaign as GNOME did, or making them a dictatorial fiat, as Unity did.
Matters might have been improved, too, if the ideas for the interfaces had been discussed among the development communities. Instead, both GNOME and Unity imposed top-down designs, announcing them only when they were ready to implement. This policy not only means that the interfaces were designed more along the lines of proprietary development projects than free software ones, but reduced the possibility of any feedback that might have improved them.
Still, what these suggestions come down to is a plea to think of context in usability. That is the path that Linux Mint has more or less been following, and the one criticism that you tend to hear of its plans is that they are being implemented too slowly.
No doubt, you could follow my suggestions and still have less than ideal results. But at least the user revolts that have become the norm in recent years might be avoided. And who knows? Someone might even produce an interface that people actually want to use.