Yeah, but, if you can't rely on tail-call optimization, you can't really use recursion and expect your code to handle any arbitrary amount of data that's thrown at it. To write robust code, you're forced to use iteration instead.
The difference between O(1) and O(n) memory usage is a big deal, IMHO...
> To write robust code, you're forced to use iteration instead.
That's exactly the point. You can use nice functional idioms in Python as long as you make the main loop(s) that crunch data iterative. Same thing in Javascript.
Adding tail-call optimization adds little to Javascript; it's nice to have but has no high return on investment (in terms of the effort you put into the language vs. what becomes impossible if you omit it).
Case in point: Think of all the criticism directed at Python. The lack of tail-call optimization is not voiced very frequently.
It makes some hard problems simple to solve. Other times you end up wasting a lot of time figuring out how to send the return value to an accumulator without accidentally creating an infinite loop or doing things twice.
Anyway, in Python you can always fake TCO using decorators. As long as someone invents the same thing for Javascript, no harm, no foul.
The difference between O(1) and O(n) memory usage is a big deal, IMHO...