На хабре у меня учетки нет, поэтому отвечаю здесь: с чего бы это вдруг XMLHttpRequest вдруг взял на себя функции браузера по части отработки скриптов? А если в том примере будет в onload setTimeout в с тайм-аутом в 10 минут - XMLHttpRequest должен будет подождать эти 10 минут, отработать скрипт, и выдать полученное? Этот объект предназначен только для передачи данных:

загрузка, парсинг, и отработка скриптов - это функция браузера, каковым XMLHttpRequest не является.

Вполне логична - она целиком соответствует концепции XMLHttpRequest: передает пользователю именно данные, но уже распарсенные в DOM. Я, конечно, понимаю, что хочется, чтобы нововведения разом решали все проблемы, и удовлетворяли все пожелания, но увы - в данном случае пожелания автора той заметки на хабре выходят за рамки разумногопредназначения объекта.
Мне в этом нововведении не понравилось следующее: c введением поддержки responseType = "document" в 11-й версии FF была выпилена поддержка задания для responseType вообще любых значений в синхронных запросах (парсинг HTML в DOM, напомню, осуществляется только в асинхронном запросе). А этот responseType может быть разным - например, с его помощью было удобно получать бинарные данные из локальных ресурсов, не адресуемых по схеме file:///:

get defaultFavicon()
{
  var defUri=Services.io.newURI("chrome://mozapps/skin/places/defaultFavicon.png", null, null);
  var mime=Cc["@mozilla.org/mime;1"].getService(Ci.nsIMIMEService).getTypeFromURI(defUri);
  var xhr=Cc["@mozilla.org/xmlextras/xmlhttprequest;1"].createInstance(Ci.nsIXMLHttpRequest);
  xhr.open("GET", defUri.spec, false);
  xhr.responseType="arraybuffer";
  xhr.send(null);
  return "data:" + mime + ";base64," + this.toBase64(new Uint8Array(xhr.response));
}

В асинхронном запросе такая схема получения работает, но если значение, возвращаемое вышеприведенным кодом (например), нужно получить где-то в начале-середине исполняемого кода, то тут начинается возня с коллбэками, псевдопараллельный код, и проч. - это просто неудобно.