In computing we have a strong tendency to create meaningful identifiers for things. There are any number of sensible reasons for this and any number of things you get from using meaningful identifiers (including that people can remember them), but there is a pair of drawbacks to it. The large one is that almost anything with meaning can have that meaning change over time; the smaller one is that almost anything with meaning can be misspelled or mistyped when initially created. Both of these lead you to really want to change those identifiers, which often leads to heartburn since many things don't cope very well with theoretically constant identifiers changing.

The power of meaningless identifiers is that this doesn't happen. Precisely because they don't mean anything, they never have to change and it doesn't matter if you made a mistake in their initial creation. This means that they can be genuinely constant things (and it's easy to keep promises about this).

This conflict between meaningful identifiers and constant identifiers and the power of meaningless identifiers to cut through the Gordian knot comes up repeatedly in different contexts. You have the cool URL problem, the login problem, the temptation to use real database fields as foreign keys, and many more. Using meaningless identifiers instead is often either completely problem free or at most slightly more ugly (when the meaningless identifier must be visible to people, for example in URLs).

Note that a truly meaningless identifier shouldn't just merely be empty of planned meaning, it should be structured so that no meaning can be read into it later no matter what its value is, whether this is by users or possible third parties. Random numbers are better than sequential or semi-sequential numbers, for example.

(And while we're at it, remember that 'randomly generated' doesn't necessarily give you things without meaning.)