Secondly, now that you have actually done that, you'll note I did not said JITters are inherently insecure. I said that "Trying to write a language that is compiled / JITted quickly, is executed quickly, is powerful, and is secure, is doomed to failure". And the reason is simple. By the time you take a powerful language and add the optimizations necessary to make it be executed quickly, your execution engine becomes complex. (For instance, the v8 engine is, what, 1.4 million lines of code? And the SpiderMonkey engine is over half a million?) And because you need the engine to compile / JIT quickly, you end up writing code that takes advantage of "bare-metal" features. And as such, you have a nasty combination of an absurd amount of code, most of which is "unsafe" (to use the Rust parlance). And from there, simple probability dictates that you will have bugs, and you will have exploitable bugs.
Now, is this inherent to JS engines? No. You could, in theory, have a JS engine written in a language that checks the code for you. As you said, Erlang, or whatever. However, that is a moot point. Because there is not a single functional browser that uses a JITter that doesn't have these problems.
And as such, here's a good reason, albeit not a technical one: precedent. I am not so... hubristic, shall I say, to assume that even though every current major browser has a large chunk, if not the majority, of exploitable bugs be in the JS engine, that the next one will be any different.
I can hope, but I will not rely on it. Especially not as I am talking about now, not some potentially-mythical time in the future.
And no, I cannot give you a technical reason. Because I suspect that the moment anyone figures out said technical reason, they will be able to design a language and/or engine that doesn't have said reason.