Worse is Better doesn't quite fit here. WiB is about getting a "basically right" prototype out, and then improving it with real world feedback, rather than waiting forever to have a perfect 1.0.
With Javascript, unfortunately, it didn't work out so well - a bunch of early bugs (which could have been quickly fixed) were preserved when Microsoft made a bug-compatible clone for IE, and then became part of the ECMAScript standard in 1996. This derailed efforts to improve the language - there is a lot of work on sophisticated implementations now, but the spec itself is buggy.
People invoke "Worse is Better" as retroactive justification for all kinds of engineering blunders, but it's a bit more limited in scope. Here you go: http://www.jwz.org/doc/worse-is-better.html
Actually, I think you're right - Javascript was frozen very early and Unix had a while to develop, but the same forces (competing commercial implementations) locked in minor errors in Unix as well.
I'd say Unix got more of its warts fixed than JS did, but that's only a difference of degree.
Mainly: The whole "Worse is Better" thing works better when you don't get stuck maintaining reverse compatibility with your early releases.
I'd say Unix and C have more warts, and more serious warts, than Javascript does. But we have come to accept those warts in Unix and C as "the way things are" whereas we generally perceive javascripts warts as such. Arguably the decision to use null-terminated strings in C in order to save one or two bytes of memory per string is an error of much greater than Y2K proportions that we are still paying for.
Javascript is a good enough (New Jersey-style) solution.
Why "fix" it?