Well, I agree that what I did was rather useless (by the way, I forgot about xedamage, didn't leave it out on purpose). The whole thing about disabling a given response was to prevent an infinite loop -- but that can be taken care of by the user rather easily by using a single boolean.
By the way, I don't see a point in interfacing with other damage detection engines. I kind of dislike IDDS -- it somehow encourages dynamic triggers, and the UnitDamageTargetEx() function is rather limited, because different kinds of attack type / damage type combinations have their own merits, something which that function doesn't allow for (for example, I might want to use DAMAGE_TYPE_ENHANCED, which is the damage type used by the hardcoded Cleaving Attack ability, but I won't be able to). As for LLDD, sure, its working principle may be the base for DamageEvent, but I fail to see anything else about it.
I firmly think that using this along with xedamage is the way to go -- without the need of using (or interfacing with) other damage detection engines.
On the other hand, I'd like to see DamageEvent being changed to use a trigger condition instead of an action (even though the speed difference is negligible, it has been proven that destroying a trigger without actions on it is rather safe -- so you can get rid of the "delay" as well). And why not use .evaluate() instead of .execute()?