Nothing undocumented going on here. Read the MDN docs again and look for "offset". It is of course the second parameter in this case since there's no groups in the regex.

Good point, I didn't think about that in my solution.
However, I argue that it doesn't break if one fighter has damageperAttack = 0.

Divison by zero (while it's not nice) gracefully evaluates to Infinity in JavaScript. Furthermore: Math.ceil(Infinity) === Infinity. In the end, one of the "factors" isInfinity, which will mean that the other factor will always be smaller, provided that only one fighter has zero damage (which was your premise). Ergo: the player with more than 0 damage will always win since he needs less than an infinite number of moves to defeat the opponent. (for any rational number q in JS, we get: q < Infinity === true)

However, if both players have 0 damage, the function would declare the first attacker as a winner (since both factors would be Infinity, that is they would be equal). Semantically, undefined would be a more fitting result as no fighter could ever win or lose. But this (and also stuff like negative damage points) is rather theoretical and not really in the spirit of the exercise.

Exactly what @damjan said. It just converts true to 1 and false to 0. Today I would probably use the + operator: +/.../.test(...) just to save another character :-)

In the last JS example test case, I get:

Expected: '{ python: 2, squirrel: 6 }', instead got: '{ squirrel: 6, python: 2 }'

The order of the keys shouldn't be a factor when it comes to object similarity. In fact, ECMAScript never guarantees a specific order when iterating over an object's keys. I suggest not using Test.asserSimilar(), but instead comparing the object's keys and values one by one.

Since we can't take real advantages of the fact that we have numbers (no mathematical approach I can think of at least), we have to treat them like strings anyway. Regex searches are built into the JS enginge and they are pretty optimized and efficient. Furthermore, from an algorithmic perspective, I think that the way this RegEx works is pretty close to how an algorithm would search that's tailored to the specific problem.
Anyway, if you're interested in performance, you could take one ore more algorithms which you call pretty optimal in terms of effiency, and let them run against the regex solution. jsPerf lets you easily create and run test cases. If you come up with something, please let us know...you can share jsPerf tests easily.

As julzhk said, the algorithm is defined to do at least one iteration. See also wikipedia and Wolfram MathWorld. Unfortunately, the case of a palindromic starting number doesn't seem to be addressed directly, so we actually have to deduce that from the algorithm's definition as a as a do-while loop (first reverse and add, then check the result => at least one iteration is required).
Also, you may trust precalculated results from various sources, e.g. German Wikipedia states that alg196(1) = 2.

Oops. I removed that one, thanks!

That's correct, I didn't think about that. Still, I think just for the sake of completeness, some more numbers < 100 should be tested.