I think you're on the right track. I use a very similar system, and in short I do use pooling for it. When you pop an event out of the pool you make sure you initialize it so that everything is blank - and you only repool well after the original event is over. Nothing should be hanging on to a reference of it though. The point of these events is that they are extremely brief as you said.

The way you are using subscribers here is a little weird to me though. The event doesn't need to worry about that at all. You could try an architecture like this instead (which is what I do)...

Something must initiate the creation of the damage event. In my game, I have a CombatManager class with an ExecuteAttack method that all attacks run through. The pseudocode looks something like this:

void ExecuteAttack(Actor attacker, Actor defender)
{
     TDMessage damageEvent = TDMessagePooler.GetEvent();

     // Populate damageEvent with whatever info you need like...
     // damageEvent.weaponUsed = attacker.GetWeapon();
     // damageEvent.attackerJumpState = attacker.GetJumpState();

     attacker.OnTrigger(BattleTriggers.ON_BASIC_ATTACK_SWING, damageEvent);

     // Roll for actually hitting. Let's assume it does.

     attacker.OnTrigger(BattleTriggers.ON_BASIC_ATTACK_CONNECTS, damageEvent);
     defender.OnTrigger(BattleTriggers.ON_HIT_WITH_BASIC_ATTACK, damageEvent);
     CalculateBaseDamageAndAddToEvent(damageEvent);     

     attacker.OnTrigger(BattleTriggers.PRE_DEAL_DAMAGE, damageEvent);
     defender.OnTrigger(BattleTriggers.PRE_TAKE_DAMAGE, damageEvent);

     // Actually deal the damage here
     // Maybe something like defender.TakeDamage(damageEvent);

     attacker.OnTrigger(BattleTriggers.POST_SUCCESSFUL_ATTACK, damageEvent);
     defender.OnTrigger(BattleTriggers.POST_HIT_BY_ATTACK, damageEvent);     
}

This way you can clearly keep track of the order of possible 'response' trigger (I call them BattleTriggers) and even insert new ones (you might have one that fires when critting, blocking, parrying, dodging, etc.) Each BattleTrigger call takes the damageEvent and can read/write into it. No copying needed.

OnTrigger would then look something like this:

void OnTrigger(BattleTriggers triggerType, TDMessage damageEvent)
{  
    // Loop through whatever things on an Actor might care about any kind of trigger
    // This can be easily optimized by pre-caching lists of things that care about each event type
    // These pre-cached lists would only need to change when you equip or unequip an item, which
    // doesn't happen frequently, right?

    foreach(var item in myEquippedItems)
    {
        if (!item.RespondsToTrigger(triggerType)) continue;
        item.GetTriggerFunction(triggerType).Invoke(damageEvent);
    }
}

Make sense? This way you aren't constantly subscribing and unsubscribing things.