Why should forEach be preferred over regular iterators?

That makes no sense. forEach should never be preferred. Yes, using map and reduce and filter is much cleaner than a loop that uses side effects to manipulate something.

But when you need to use side effects for some reason, then for … in and for … of are the idiomatic loop constructs. They are easier to read and just as fast, and emphasise that you have a loop body with side effects in contrast to forEach which looks functional with its callback but isn't. Other advantages over forEach include that you can use const for the iterated element, and can use arbitrary control structures (return, break, continue, yield, await) in the loop body.

This reasoning in Airbnb style guide applies to array methods that are used for immutability, which are filter, map, reduce, etc. but not forEach:

This enforces our immutable rule. Dealing with pure functions that return values is easier to reason about than side effects.

So the comparison is more like:

// bad
let sum = 0;
for (let num of numbers) {
 sum += num;
}
sum === 15;

// bad
let sum = 0;
numbers.forEach((num) => {
 sum += num;
});

sum === 15;

// good
const sum = numbers.reduce((num, sum) => sum += num, 0);

sum === 15;

Generally, for > forEach > for..of > for..in in terms of performance. This relationship is uniform in almost all engines but may vary for different array lengths.

forEach is the one that was significantly improved in latest Chrome/V8 (almost twice, based on this synthetic test):

Since all of them are fast, choosing less appropriate loop method just because of performance reasons can be considered preliminary optimization, unless proven otherwise.

The main benefits of forEach in comparison with for..of is that the former be polyfilled even in ES3 and provides both value and index, while the latter is more readable but should be transpiled in ES5 and lower.

forEach has known pitfalls that make it unsuitable in some situations that can be properly handled with for or for..of:

• callback function creates new context (can be addressed with arrow function)

• doesn't support iterators

• doesn't support generator yield and async..await

• doesn't provide a proper way to terminate a loop early with break