Names are not cheap, they are actually expensive. Names look cheap because they are easy to create, but they create clutter and uncertainty (over what name is still being used by what) that makes them expensive in the long run.

I believe this is an illusion.

It's not the names that are expensive; it's the clutter. The key is not to avoid creating names, but to be disciplined in their creation and use--to create a definition of what each name specifically denotes, and not to casually overload the name with other meanings.

It's my experience that it's not actually the names that we tend to lose track of, but the applications associated with them. If we're asking "what is still using the name 'doohickey?'" we are actually more interested in knowing "who or what is using the set of services that the name 'doohickey' described?" However, if that set of services was lumped in with an existing name rather than assigned the name "doohickey," the clutter is hidden: you still don't have an answer to the question, but you don't have a name--a visible manifestation of untidiness--sitting there reminding you of that fact, and it's easier to let the "doohickey" services moulder in the shadows until you truly need to address the underlying issue.

Conversely, whenever you reuse an existing name for a new purpose rather than create a new one, you potentially sacrifice some flexibility: if you later decide to move (or virtualize) any of the resources associated with the name, then changing all of the places where the name is used will be a lot more expensive than keeping track of another name would have been.

The cost of names should be of less concern than the value they provide for that cost.

--Dan