The problem is that there's only one namespace for object properties (ignoring the Symbol feature in ES2015 for now). There are some object properties that you do want to be enumerable, and some you don't. The properties that contain object data and relationships to other objects share that namespace with the names of methods.
The for ... in loop looks not only at the properties of the object directly involved, but also up the prototype chain. That's probably the most likely use for non-enumerable properties: the methods that you may want to put on a prototype object probably don't need to be enumerable.
To me the real reason not to use for ... in when you're iterating through the numeric-name properties of an Array instance is that there's no guarantee you'll iterate through the indexes in any particular order. Though most runtime systems do give back numeric-name properties in the obvious order, the specification for the language absolutely does not require that that be the case. By using an explicit numeric index in a plain for loop, you thereby explicitly control the iteration order.
People who write JavaScript code for use in contexts where there'll be other code running over which they have no control (think advertising-supported sites, or sites with lots of metrics tools) know that relying on built-in prototypes not to be polluted with random junk is deeply unwise. Using for ... in puts your code at the mercy of the worst coder contributing to that third-party code.
Modern implementations have Object.keys(), which returns the enumerable "own" property names of an object; that is, the names of properties directly on the object, and none from the prototype chain.
