On most Operating Systems you can customise the system colours. The reasons for doing this range from the insignificant (you just like purple a lot), to the incredibly significant (you are colour-blind or visually impaired, and you want a contrasting colour scheme that would look really stupid to anyone else).
While they increase the freedom of the user, customiseable system colours reduce the possible range of expression within an application. The typical computer can display several million different colours, but an application designer can rarely use them, because they are restricted to the small set of named and customiseable colours. If you are designing some interface element, the colour of which can not be described in this language, you just have to pick the one that is ‘close enough’.
Using colours in a User Interface can be a bad thing if the colour-choice is bad (making for an ugly application), or if colour is the only thing that distinguishes a particular element (making the feature unuseable for the visually impaired). However, colours can be a useful tool, and colour is an important way of communicating with people who can see it.
Notably, Mac OS X only has two supported colour-schemes: Blue (with the familiar aqua controls), and Graphite. Graphite was provided for graphic-designers who found the blue interface made it harder to judge colours while working on a picture. When designing an OS X application you can pretty much rely on having black-on-white windows with those horizontal stripes. That said, the UI toolkit still has a set of named system colours, and recommends you use them instead of defining your own.
Speaking in Tongues
Full skinnability adds to the limitation of expressability by limiting the available vocabulary of an application to those interface objects that are already supported by the available skins. This problem appears in skinnable toolkits, such as GTK+, or Java Swing.
A common metaphor in interface design is that of language. The vocabulary of a user-interface lies in the set of available controls. The controls themselves are nouns. The state of a control is an adjective. The actions that we can perform on those controls are verbs.
Most platforms come with a particular dictionary of available nouns, verbs and adjectives, and developers are encouraged to stick to the official dictionary as much as possible. Firstly, users find it easier to understand an application that way because the language is familiar. Secondly, if the official language is changed or expanded in the future, it can be done in a way that doesn't conflict with existing applications. The exception to this rule is games, but the analogy holds—fiction-writers have always been able to be freer with language than technical writers.
Sometimes, however, you come across something that you want to represent in an application that, as hard as you may try, can not fit into the existing vocabulary. At that point, you must create a new control, and wear the cost of having your user learn it for themselves. New words are invented by looking at existing words, and maybe crunching a few of them together, or making something that looks very similar to the words you almost mean. Similarly, you make a custom control either by combining existing controls, or by looking at the existing controls and thinking what changes you would need to make to them so that they have the capabilities you want.
When an interface is skinnable, each different skin becomes a dialect of the language. So if you want to write a custom control, you are no longer introducing a new word to a single language, you're introducing the same word to an infinite variety of languages. You either have to choose a control that looks natural in every skin (impossible), or ‘translate’ your control to each skin (far too much work). Designers of skinnable applications come across this problem freqiently—having to render all existing skins incompatible (or horrendously ugly) because the application has some new interface element that only the default skin supports.
It is even worse when skinnability not only alters the appearance of the generic controls (“This is the appearance of the class of all buttons”), but allows the customisation of specific controls (“This is the appearance of the ‘Go Back’ button). Most skinnable applications, such as Winamp or Mozilla take this route.
For a pathological case, consider Mozilla. The hypothetical case is a developer wishing to write a Mozilla add-on that places a “blog this page” button on the toolbar. Like all buttons, it needs an icon, but unfortunately ‘Blogger Button’ is not a supported noun in Mozilla's skinning vocabulary.By default, Mozilla comes with two skins (Modern and Classic), and there are several popular third-party skins such as Orbit (which the author uses).
Unless you want to draw different icons for each of the popular skins, you are stuck with the fact that your icon will only fit in with one skin, and be inconsistent with all the rest. Inconsistency is a very bad thing in User Interface design, an icon that is incongruous will make it more difficult (and take longer) for the user to target any toolbar button as a result. For anyone not using the same theme as you, the overall user experience of your add-on will be negative, and people will not use it.
The problem with skinning is... users like it. From the point-of-view of a user, skinnability gives them greater choice within an application or environment because they can customise how it looks. Many people spend inordinate amounts of time on this pursuit. Unfortunately, from the point of view of an application designer, skinnability ultimately reduces the user's choice, especially when it comes to applications that may innovate in terms of their design, by reducing the vocabulary, or palette available to the developer.