It affects more than just a few C library details. In particular, `static' variables can be a problem. Link-time RTLD_LOCAL appears to imply the presence of multiple instances of the library executable mapped into memory, or at least multiple copies of their rw segments. Otherwise you'd encounter funky behaviour differences depending on whether two unrelated libs happened to link to the same versions of some 3rd lib or different versions of it.
That makes it hard when libraries at the same linkage "level" (say libh and libi) want to pass around objects that may, either overtly or behind the scenes, rely on shared static data (library-internal caches or the like) in a library (say libj) they both use. Of course, they can't pass libj objects across library boundaries anyway unless they know they're using at least a compatible version of libj, since their layout might and/or meaning not be compatible, so they may as well share the same instance of libj's rw data segment too, as if it were RTLD_GLOBAL.
This sort of thing is very common in things like application frameworks (qt/gtk/etc) and plugins.
I seem to remember that Mac OS X tackles this by defaulting to something like RTLD_LOCAL linkage, but allowing objects to specify global linkage instead. That's vague memory only though, and I haven't hunted down any documentation to confirm it.