an example - I might have a view which shows all the user profile documents in my app. If that same view is used to show the documents in the application outline, used in a lookup function, and used to display a picklist to the user so they can select a user document, I would give it four different names - well.. probably only 3 but for argument's sake, let's go with the following 4...
1 - the design element name - (eg "appUserProfiles")
2 - an alias used for the interface - (eg "userProfiles")
3 - an alias for the lookup - (eg "lookupUserProfiles")
4 - an alias for the picklist - (eg "picklistUserProfiles)
Of course, this is assuming the same view is used for all and this may not be the case, it's just to help illustrate the point.
I'm sure a lot of people have been cluey enough to re-use the same view where possible, but it's the use of the alias which allows you to have more adaptable code - all of your lookups use a "lookup" prefix, picklists use a "picklist" prefix and wherever else, you use a common link to your design elements. Add to that the additional benefit where, if the desired functionality of one of the elements changes, you can create a new element, give it the alias, and there's no need to trawl through the code looking for where you used the name of the view - the new view just takes on the alias and it's removed from the old one - the code/outlines etc can stay the same.
It also gives you an indication in the design element where the view is being used by the application - instead of thinking that the view you're updating is just used in the interface, you can tell immediately that it's used in both a lookup and a picklist, so you probably shouldn't go about changing the sort order or key.
So - there's another to my "do" list that I quite like to make sure that I do - it's one of those things that you may hardly ever use, but when you do, and it makes things easy, it's so worth it.