Kanican's LJ article is the best read by far of any that I've seen. It's how I've been thinking enmity worked myself more or less. There is no hard cap. It decays at the same rate for everyone. There is only one type of enmity. Adding +/- enmity items just alters the gain per action and has absolutely nothing to do with decay rate.
BTW, I loved his thundaga/sleepga example. It's sooo true and anyone that has voked or stunned things off sleepers in dyanmis has seen it in action.
The biggest reason I'd ague against enmity actively influencing decay is that in order for that to happen, the programming model has to become more complex. A dumb coder would check everyone's enmity every cycle. A smarter one still has to keep separate decay rates for every person based on enmity at the time of the action. What if you have different levels of enmity on at the time of each action, too? You really really don't want to save each and every action on the critter and decay it individually by enmity. Do you reset the decay rate of the previous ones? No. Decay by enmity is just too complex to code for a game programmer. They're typically underpaid and underskilled, but highly motivated because they just think working on games is "cool". And, any real professional would pitch that idea out based on it requiring excessive resources without yielding any significant difference over simpler methods. There are a lot of fights active on the server at any given time; coders will want fight processing to be fast and light.
So, based on coding practice, I'd punt: theories that require enmity to function outside of "at the time of action", theories that require anything other than a single enmity value per player to be stored by the server, and theories that require expensive decay calculations.