Obviously, having a simple, denotative name for a library is a good thing, but it's only really effective when the name can succinctly describe the features and functionality of the library. It's also easier, when those features are limited to a few well-known abstractions like FileSystem, ProgramOptions, Graph, etc. This arguably isn't the case for Joel's work. The breadth of abstractions represented by those libraries (DSELs, Parsing, Generating, etc.) aren't necessarily best described by a single term.
Why Boost.Parsing or Boost.Generating are bad? I agree, these names don't look as fancy as Spirit or Karma, but, personally, I usually care more about practical matters than exterior fancyness.
In such cases, it's probably better to pick a neutral name (Spirit, for example) than to pick one that could be misrepresentative or misleading.
I think the crux of the problem is not really the name of the library, but the ability to associate a library with a task. I think that Joel is right that it's a presentation issue.
The documentation index is just a flat listing of libraries organized alphabetically, which is kind of an arbitrary presentation and not especially conducive to this kind of task. The category listing is substantially more useful in these regards. I would argue for moving this to the top-level documentation page or providing a very obvious link to it.
Perhaps there are even better presentations for the breadth and scope of Boost libraries.
I agree that categorized index could help a lot. However, I can't say that it would allow library names to be completely irrelevant to their purpose.