"...because people apparently don't want to write some service-level code without sucking in libraries that other people don't want to use."
Quite the opposite. Prior to having an established and shared service communication framework (D-Bus) the only viable options were collaboration on specifications and low-level libraries.
The people involved were aware of the decoupling provided by a service based approach, oherwise D-Bus would have never received the buy-in it has today.
But it is important to understand that creating such a technology and respective application developer API and raising awareness of the benefits over its drawbacks takes some time and that having the means doesn't automatically imply replacements for existing implementations happening either.
"...but my impression was that people were committed to pooling effort and not reinventing the wheel."
I think your impression is correct and also that this has indeed happend. A lot of shared infrastructure has been created and is being used not only by "the big guys" (GNOME, KDE) but even by individual application developers.
"All you need is agreement from everyone that certain tools will be around to do the job."
I don't think any of the tools got removed or altered in an incompatible fashion, but not all tools necessarily export the same feature set (e.g. Thunderbird initially? did not support attachments in mailto URIs).
Another difficulty was that e.g. xdg-open used the best available tool for a given task, which however might not have been intended to be basically the runtime equivalent of public API (thus not necessarily being governed by the same strict policies).
"As you already mentioned, getting agreement when no-one can see the point [...] is pretty tough"
That's not what I meant. Sure, not being aware of a problem makes it difficult to see the need for a solution, but that never resulting in people blocking a solution. It just shrinks the pool of people available to work on said solution. Surprisingly those in need of the solution (e.g. people working on a technoloy stack without launcher API) are even less likely to contribute, making it even less likely to draw resources from those who are already covered.
"...and was recently notified that kfmclient has been renamed to kioclient in KDE 4 but takes the same options."
Actually kioclient is an additional tool that does have fewer dependencies (and is therefore always available, not just when the KDE workspace is installed).
It even comes with a simplified interface named kde-open which is specifically intended for use cases like xdg-open, while kfmclient had such capabilities just incidentally, its purpose being a console interface to KDE file manager program.
"All I need to do is to wonder briefly how hard it would be to make a symbolic link for compatibility..."
Which would have made sense if kioclient had replaced kfmclient and I am sure that is what would have been done. Anyway, purely hypothetical due to stories about kfmclient's death being hugely exagerated :)
"D-Bus is but one mechanism that should make decoupling [...] easier"
Sure, but the irony I was referring to was not that D-Bus would have had a negative effect on collaboration (it had a very positive effect), I was referring to the, let say call for collaboration, being posted as a reply to a comment by a person who has figuratively enabled a new universe of collaboration.