Coercion Performances

There are cases where JS coercion may be wanted/needed/necessary, at least logically speaking.

A classic case is a list of primitives, e.g. strings, or numbers, and a check we would like to perform without creating a new function each time.

// recycled function
function alreadyThere(value) {
  // wanted coercion, no cast needed
  return value == this;
  // shitty code, logically speaking
  // one cast per iteration
  return value === "" + this;
}

var listOfNames = ["Me", "You", "Others"];

// the pointless check
listOfNames.some(
  // the recycled callback
  alreadyThere,
  // the *passed as object* this
  "You"
); // will be true

Now, for above specific case anyone would use an indexOf but this is not the point.
The point is that in some case we may want to do more complicated stuff and compare the result with this

// know if word was already in the dictionary
function alreadyThere(value) {
  return value.toLowerCase() == this;
}

// convert the check once per iteration
listOfNames.some(
  alreadyThere,
  "yoU".toLowerCase()
); // still true

It's About Optimizations

The whole point is to try to perform as less runtime computations as possible.
Following this logic, we may decide to lower-case all items in the list once, and never again, but unfortunately this will require duplicated amount of RAM used per each collection.
The String#toLowerCase() is fast enough for a not so frequent check so why bother the RAM?
The optimization is also to avoid this.toLowerCase() per each entry of the dictionary.
The concept here is again simple, avoid duplicated entries in a generic list of chars, but things may be similar with numbers.

Performances

I have created a specific test able to understand performances gap between coercion and cast per iteration.
Surprising Google Chrome seems to be able to optimize in core once per iteration the cast, resulting almost twice as fast as competitors.
Specially on mobile, the in core coercion seems to be faster, sometimes almost twice as fast as the cast per iteration is.

JIT Oriented Development ?

I believe we should code logically, rather than trust JIT optimization. What I mean is that performances test are always welcome but we all know that better logic and algorithms are always winning in therms of performances and maintainability. In this specific case, specially where mobiles suffer the most, I would never suggest to do the cast per iteration: first of all because only one engine seems to be able to optimize such cast, but we don't know if a more complex object/scenario would perform that well, secondly because if I see a cast per each loop iteration I start smelling laziness all over the place ... the boxing/unboxing has always been a well known problem performances speaking, so how can a developer approve a logic similar to (String)alwaysSameObject per each iteration?

As Summary

Tools such JSLint should just do their business in these cases ... coercion is wanted/needed/logical, and unless every browser will show such gap in common tasks against coercion, I will rarely promote a cast per iteration ... and you know what? I believe that gap in Chrome, is a missed optimization in Chrome itself.