Not exactly. LibDBIcon covers the tooltip and clicking functionality, so it will serve launchers but you cannot properly handle .text updates and the like, in a minimap button. It's kind of ironic that we would even mention this as an alternative, since one of the original arguments that spawned LDB was getting rid of the "minimap herpes" produced by LFB, if the display addon was not present.
I also feel that the whole issue has been blown way out of proportion. Obviously if one is using LDB to provide optional features in an addon that is/was designed to work as standalone, then he does not *need* to embed it. He can just optionally include the code in the way Xinhuan has suggested, or make it a LoD addon harddeped to the "parent" that will only be loaded if the user desires it (and he can handle the freaking embed any way he likes it). In that case, imho, using LibDBIcon does have a purpose. But "forcing" LDB specific plugins, that are actually designed for the sole purpose of updating those attributes, to now also register their objects in a global table, just in case LDB isn't present, for the sake of not embedding it, so we don't have to work around the WowAce packager system (which we shouldn't need to do in the first place), is mind-boggling. There is no significant benefit or any special reason to do so, especially if said plugins are not even hosted here.
Personally, I partially agree with Orion (minus the "abusively obscene" part and removing support) and will keep the LDB embed straight to the .toc. There is really very little reason to try and invert "workarounds" for the packager, so that both lib and nolib packages will work as expected, not to mention cumbersome. I also don't see the problem with LS and CBH getting embedded via the .pkgmeta. It's been like that since hrm ages ?