Such approach occurs once in a thousand or even more solutions in JS... Awesome, many kudos and great respect to author!

+1 for the upper limit.

I like this solution the most.

Is there any reason as to why you would not want to make sure the number coming out is too big?

(Other than an assumed small effect to proformance)

While this solution works for free-standing functions as tested in this Kata, it would fall apart when applied to object methods. Consider this test case:

function Rectangle(width, height) {
  this.width = width;
  this.height = height;
}

Rectangle.prototype.area = function() {
  return this.width * this.height;
}

Rectangle.prototype.area = Rectangle.prototype.area.wrap(function(original) {
  return original();
});

var rect = new Rectangle(2, 4);
Test.assertEquals(rect.area(), 8);

This would fail with expected NaN to equal 8 as the solution binds this to the value it had at the time of the call to wrap, rather than to rect at the time of the call of the wrapper.

some() returns a boolean, forEach() does not return a value. A return can be added as a seccond line.