OK, je suis d'accord avec les arguments n°2 et 3, pas avec les autres ^^

1 - C'est un langage, et même si aujourd'hui on fait systématiquement la confusion entre un langage et sa bibliothèque standard, je continue à préférer les implémentations qui séparent clairement les deux (par exemple C# et .NET). Avoir une bibliothèque standard liée au langage limite sa portabilité, c'est pas pour rien si JS s'est mis à être utilisé en backend aussi facilement.
4 - C'est faux depuis 2015 ; la seule justification était la portée de "var" qui oblige à faire des lambdas mais c'est terminé avec "let" qui propose une portée par bloc comme dans une majorité de langages.
5 - Ben comme tu dis, ça n'est pas une table de hash. Ça peut servir de base pour en implémenter une trivialement, mais pour les 99% de cas où je ne veux pas une table de hash je suis content qu'on ne m'impose pas une interface dont je n'ai pas besoin. Par ailleurs, exposer des choses comme ".length" directement sur l'objet racine, en plus d'être un choix très arbitraire, aurait incité les développeurs à utiliser cette propriété et tué du même coup une large partie des optimisations que peut faire le JIT.
6 - Comme pour le point n°4 tu as le choix, puisque malheureusement il y a maintenant des classes en JS aussi. Perso je ne suis pas convaincu, bien sûr que si on essaie de faire des classes avec un langage qui ne les supporte pas nativement on arrive à un truc ignoble, tout comme si on essayait d'implémenter l'héritage par prototype dans un langage objet on aurait un résultat atroce. Mais c'est l'exemple lui-même que je trouve idiot : quel besoin d'implémenter à tout prix des classes comme si c'était le seul paradigme de programmation autorisé ? Sur ce point ça ressemble beaucoup à l'argument "la syntaxe est moche", dans une variante "il n'y a pas de classes et moi j'aime les classes".