LDAP would allow sending events to drivers running on other engine servers, so has at least some added value to compensate for the complexity, though I do not think it's a killer feature.
A while ago I was looking for a way to send an XDS document to another driver's cache for processing.
I already knew how to call DXCommand to inject an event for immediate asynchronous processing or send a command for synchronous processing to another driver but could not find an option to queue an event into cache in that class, which seemed a bit odd, since that's an obvious third option that would make sense to offer.
Luckily Peter Lambrechtsen wrote and published a library to fill that gap a while a go on Cool Solutions, now available here. So I gave that a try and while it looked overall promising I soon ran into a known bug that needed fixing. And while I was at it, I added tracing support and an example Designer project for easy evaluation as well.
Downloads and source code are available at GitHub.
I have an ECMAScript version of Peter Lambrechtsen's code.
Know that LDAP is way of the future, so one day will switch to the LDAP approach. Feel the whole TLS, auth and also other Microfocous LDAP classes smashing their way to dominance (eDir bidir shim for example) makes the LDAP / ECMAScript approach far more complex than the good old school approach.
See https://www.netiq.com/documentation/identity-manager-developer/driver-developer-kit/javadocs/com/novell/nds/dirxml/ldap/QueueEventRequest.html if you what to do this via LDAP.