Enter the microcomputer in the mid 80s, with its 16 bit memory model and single wimpy core. (ignoring 8 bit toys). Running a garbage collector on such meager machines wasn't practical, so malloc/new and free/destroy it is, then! (yes, the irony is precious when Java appears a decade later)
After the early 90s, the Simula programming model has been pretty much the only thing taught to developers - a few self-taught people perhaps aside - so it's the only way they think.
Trying to convince these people that large chunks of their logic should be immutable data, processed in a "one way path" (directed acyclic graph) through functions, some of which are built of or build other functions, and that input and output types (which can be traced backwards and often inferred rather easily) can be assembled "on the fly" makes no sense to them.
It's almost like standing on a box on the street corner and trying to preach at people in Greek. They don't understand a word you are saying. "Get these freaky cultists out of here!" :-)
By the way, there is nothing like Scheme + Emacs for interactive development. You can write functions, execute a buffer, and perform your data manipulations in real time, patching your functions as you go.
It's freaking magic.
>They don't care if first class functions are sexy.
It's not about being sexy (and believe me: first class functions aren't): it's about getting a very useful feature right, something many languages seem to have trouble with, despite the fact that Lisp (and ALGOL, IIRC) got it right in the 50s.
I think your attitude is more that nothing is really bad with js relative to other languages, more so than actually trying to understand why it draws a lot of criticism, which is what you claimed and what I tried to link to.
(I'm ignoring the error handling thing, as I have not done enough server side JS to have a good feel for how the Node API handles things like I/O failures)
IDEs are starting to have better support for Javascript (or similar dynamic/functional languages). In the near future, the IDEs should effectively have type inference. Once you relegate (mutable) OOP to a tool of last resort, and embrace immutable value objects plus (higher order) functions as your primary methodology, you get the automated error checking and much less drivel to read through during maintenance.
OTOH, I suppose this means the dynamic/FP languages will remain a productivity lever for motivated "experts" only, sadly. At least until there is enough butt-kicking in the market that Java (and its ilk) will be displaced as was COBOL before it. COBOL was "safe" and fast, but we finally reached a tipping point were it was too painfully obvious that it simply wasted too much time writing and reading it.
Otherwise, you certainly had first class functions, just not always with any external state captured.
https://en.wikipedia.org/wiki/Man_or_boy_test
I suspect TurboPascal was in the "boy" camp, in that a reference to a function (or procedure) would not have any external state bound to it.
The answer doesn't really end up being static vs dynamic, but rather how dynamic languages often lack the other facilities that make programming in the large easier, and Eric Lippert uses js as an example.
Companies with a lot of money at stake have spent a lot of money and effort on things that transpile to js. The people making these decisions are almost always quite smart and very practical. They don't care if first class functions are sexy. They just want to write high quality code quickly. If they've spent so much time wrapping it up, you know it's because they had serious issues being productive at scale with js. They, and people on their team, probably got extremely frustrated along the way. Hence the hate.