Not only is there less crawling around looking for symbols, you're no longer in trouble when two libraries export the same symbol.
Especially given libraries are found by name, and symbols by name, where "type information" or "is that actually the library I wanted" are afterthoughts.
> you're no longer in trouble when two libraries export the same symbol.
Whether you use direct binding or symbol versioning, either way you don't have a problem with multiple libraries exporting the same symbol.
By the way, this is the fundamental problem with static linking for C: it's still stuck with 1970s semantics and you can't get the same symbol conflict resolution semantics as with ELF because the static linker-editors do not record dependencies in static link archives.
The key insight is that when you link-edit your libraries and programs you should provide only the direct dependencies, and the linker-editor should then record in its output which one of those provided which symbol. Compare to static linking where only the final edit gets the dependency information and that dependency tree has to get flattened (because it has to fit on a command-line, which is linear in nature).
Not only is there less crawling around looking for symbols, you're no longer in trouble when two libraries export the same symbol.
Especially given libraries are found by name, and symbols by name, where "type information" or "is that actually the library I wanted" are afterthoughts.