Why are you storing damage in an associative array? If damageTaken was an array of { id, value } objects then Link would work perfectly for you.
var item = Link(this.damageTaken).max(function(item) { return item.value; });
item.id // the answer you are looking for.
I could somehow try and do a basic test to see if you are iterating over an object or a hash map/associative array. It might even be a parameter in Link:
var item = Link(this.damageTaken, { hash: true }).max(function(item) { return item.value; });
item.key // the answer you are looking for. Notice it's called key now.
Then when it searches this.damageTaken it knows it's a hash map and so 'recasts' it to a { key, value } pair and then continues the chain like before. This way you don't have to change the underlying data and it can iterate over arrays as well as objects.
Actually that may be quite neat. Picture using Link for certain hash maps:
// updating health of all poisoned players in an associated array: ["Jim" = new Player(), "Bob" = new Player()];
Link(this.players, { hash: true }).pluck("value").has("status", "poison").invoke("hurt", 5, "green");
// or you can do this with a normal array:
Link(this.players).has("status", "poison").invoke("hurt", 5, "green");
It doesn't seem faster but in some situations it can be convenient. Sometimes storing players in a table like the above is a convenient way of keeping track of them and with Link you'll be able to iterate over it.
I'll give it some thought right now. My only concern is such a feature won't play nice with features that have a '.run()' method tied to them since they assume you iterate over an array and hence why they are so fast. I really want to redesign the library into a 0.3.0 version that isn't as bulky. I'll have to narrow down what I can get away with so I don't have to write so much repeated code. It'll likely only work in modern JS environments since I'd make use of newer JS features.