I find JS useful for scripting - both are interpreted. Shell (bash) script complexity increases exponentially with length of script- starting from there being only 255 error values, the difficulty of returning values from sub shells and error handling. Making a system call from JS requires a constant few times more characters than calling from a shell script, but complexity doesn't increase nearly as fast as the script gets longer. JS also has many OS functions of its own to replace system calls.
JS shines when -a priori- only a single thread is needed, there is not a lot heavy duty computation (or that is delegated), and there are a lot of logically independent "lvirtual" threads which are sitting around blocking on i/o most of the time. With promises, pipes, and a good automated scheduler for the "virtual" threads (all interleaved in the same real thread). Yes, a garbage collector can misbehave, bust just as it is possible in C/C++ to write code without memory leaks by following clean design and some basic rules, the JS garbage collector be reliable if the code follows clean design and some basic rules. If the JS performance is sufficient for the task than it has won because it far faster to develop with than C/C++.
On the other hand, JS is slow starting new "real" threads and that can't be fixed. C/C++ shines there. With JS, true parallelism must use system messaging between long term threads.
Also, the ad hoc nature of JS' evolution has resulted in some ugly JS-special syntactical warts and potholes that can't be removed. That's OK if you just turn the lights off to get the job done.
Biting the hand that feeds IT
