[B~Vladi]

Sweet, прости, я норм к тебе отношусь.

И вообще, твой пример никак не связан с циклом for..in!

Ок, вот другой пример, когда есть дефолтные значения:

var defaultOptions = {};
function Constructor(options){
  for(var property in defaultOptions){
    if(defaultOptions.hasOwnProperty(property)){ // Проверяем только нужные свойства. Вот здесь hasOwnProperty обязательно.
      // Делаем нужные действия
    }
  }
}

Когда нет дефолтных значений, проверять нужно так:

function Constructor(options){
  // Допустим, нам нужно проверить конкретное свойство
  // Если тип не важен:
  if('prop' in options){}
  // Если важен:
  if('prop' in options && (/* тут проверка типа */)){} // prop in obj - тоже обязательно
}

Но никак не hasOwnProperty! Его нужно использовать только для "своих" объектов и то, если они не имеют кастомных прототипов.
Из этого видно, что значением может оказаться ваше кастомное свойство из прототипа.

тебя спрашивают, почему плохо расширять Function.prototype, а ты объясняешь, почему плохо расширять Object.prototype. Так в Object.prototype никто и не лезет.

Откуда ты можешь знать, из какого прототипа берутся значения? Если объект приходит извне и тебе нужны только значения свойств, нельзя смотреть на тип объекта. В примерах выше я могу в options передать и функцию, если мне будет так удобно.

Что я этим хотел сказать:
Если везде применять hasOwnProperty и проверять тип объекта - создаются ограничения, в частности, нельзя уже использовать наследование. Если расширять прототипы нативных конструкторов - они начинают везде обрабатываться, что может привести назад к использованию hasOwnProperty или даже к багу. Замкнутый круг. В каком месте его разрывать - каждый решает сам для себя, о чем я писал выше. Все полюсы и минусы я показал.