Probably because JavaScript is the worlds most popular programming language, it's portable, has the largest package manager, supports the shell's non blocking requirement, and the current version (ES6) has a better stdlib than previous versions.
You're wrong on about three of those statements, but note that the same hand wave could have been made for Perl ten years ago. That would've been a poor choice then for the same reason Javascript is a poor choice now.
Not new. Javascript is not the most popular language, does not have the largest "package manager" (nor standard library, nor package library which is what I think you mean) and more importantly it does not have the most programmers specializing in the problem domain at hand -- shell functions. Moreover the referenced toolset doesn't even use Javascript! You merely jumped in blind to promote your favorite tool. Also if you want to play HN-by-the-book then you should refute my argument why Javascript shell scripting in 2016 from a cold start is somehow better than Perl shell scripting in 2000 given its lead back then.
And the most popular girl in my high school can't ride a motorcyle. I took her to prom but I'm not inviting her on my next cross-country ride. What's your point?
Regardless you don't pick a toolset based on popularity. You choose it based on capability. 100,000 front-end HTML developers asking the same "how do I regex?" question on StackOverflow 10,000 times doesn't pre-qualify an ecosystem as the perfect tool for shell automation.
And at this point you're just trying to save face after you jumped in to explain why it's such a great idea that this project uses Javascript. It doesn't. I'm moving on and suggest you do the same.