Mettre les ECMAScript & Python dans le même sac, c'est tout de même confondre les échelles de bordel.

ECMAScript en termes de langage et d'écosystème, c'est effectivement la foire à la saucisse. Les dernières aberrations sur le dépôt NPM officiel ne sont pas si vieilles.
Et l'"avantage" de ce langage était de s'exécuter dans les navigateurs. En faire un serveur, c'est une autre aberration de nature.

En partant de mon point de vue sysadmin d'un besoin de langage interprété pour exécuter des scripts dans des environnements serveur, Python est le meilleur compromis que je connaisse à ce jour.
On dépasse rapidement la capacités et la maintenabilité d'un script Bash, et l'environnement de l'interpréteur avec ses dépendances et gérable/isolable par besoin, modulo quelques outils pour fiabiliser la gestion des dépendances.
Des bibliothèques réputées existent pour à peu près tous les besoins de base non déjà inclus dans l'interpréteur de base. Gare à s'en éloigner cependant : au même titre que le langage de base souffre déjà de beaucoup d'irritants, on rentre rapidement dans (et souffre donc vite de) la foire à la saucisse des modules tiers.

J'ai historiquement commencé par PHP en langage interprété, mais il ne m'est jamais apparu adapté à mes tâches de script déployables/répétables déterministiquement en espace utilisateur sur une infrastructure.
Il reste en revanche pour moi en FPM comme excellent moteur de pages Web dynamiques, avec isolation du moteur et confinement via groupes de fils de travail au sein de celui-ci, ainsi que le filtrage des arborescences accessibles.
Et là-dessus, µWSGI de Python est une autre histoire.
Je ne parle même pas de NodeJS.