Think for a moment about a standard, mundane filename. That filename refers to a collection of data that happens to be stored somewhere on disk. We can call the file's contents an object—the contents are information, and there's probably some code lying around that knows how to provide some functionality for that information. An object such as this would allow clients to manipulate its contents through interface pointers.
Now, the filename itself is not the object but is merely a reference to where the object exists in a passive state. The intelligence about how to use that name is concerned with bringing the object—the file—from its passive state to its running state. But a filename by itself is unintelligent; all the knowledge about how to run the object and how to manage that filename persistently must be coded into the client that intends to use the file object. Usually this isn't much of a problem because applications have been working with file objects for a long time.
In a component software environment, however, there are many more types of objects than those whose data exists in a file. There are objects that passively reside in databases, in e-mail messages, and in specific locations inside other files as well. Other objects represent some running process and don't have a passive state at all. Nevertheless, clients need to maintain symbolic links—that is, clients need persistent names that they can bind in order to run objects and retrieve interface pointers for them. Clients also need names to describe specific parts of a file (or parts of parts of files), database queries, remote computations, administrative operations, and so on. Literally any data set and any process or function in a computing environment can be given a name, and a naming and binding architecture allows clients to exploit those resources in efficient and powerful ways.
This is why unintelligent names are such a problem and are, in fact, antithetical to component software. The addition of a new type of name into the environment requires revisions to all the clients that want to make use of that new type of name. In other words, each client has to contain specific code in order to work with any particular type of name for particular resources. If they don't know how to use the name, the resource is unavailable to them. This is completely impractical in a component software system, in which we have the ability to change, modify, update, and redeploy software components independently of any other component and in which QueryInterface allows us to add new interfaces and new features without losing compatibility with existing clients.