As a precise example as to why this would be a useful feature: vCenter alarms SNMP trap notifications. At least in my experience these are sent from vCenter as v1 traps but all the juicy information is in the trap variable bindings. Here's a trap sent from a CPU Usage Alarm:

1.3.6.1.4.1.6876.4.3.304.0: Green
1.3.6.1.4.1.6876.4.3.305.0: Red
1.3.6.1.4.1.6876.4.3.306.0: alarm.VmCPUUsageAlarm - Metric CPU Usage = 100%
1.3.6.1.4.1.6876.4.3.307.0: SERVER-1
1.3.6.1.4.1.6876.4.3.308.0: 3
enterpriseOid: 1.3.6.1.4.1.6876.4.3
generalCode: 6
snmpVersion: v1
specificCode: 203
sysUpTime: 1778505188
trapVariableBindingCount: 5

All the /really/ useful information is in the trap variables:

1.3.6.1.4.1.6876.4.3.304.0 (vmwVpxdOldStatus)
1.3.6.1.4.1.6876.4.3.305.0 (vmwVpxdNewStatus)
1.3.6.1.4.1.6876.4.3.306.0 (vmwVpxdObjValue - What alarm got tripped!)
1.3.6.1.4.1.6876.4.3.307.0 ( vmwVpxdTargetObj - What vCenter object tripped the alarm!)

Being able to filter on the contents of bound variables, and address them as tokens in alarm subject/message, as something like ##TRAPVAR01##, ##TRAPVAR02##, ##TRAPVAR03## would be a massive workflow improvement for us.

SNMP Trap Eventsource