Efficient javascript needs to be JIT'ed, but that means your app needs to be granted API access to map writeable memory as executable, which is a security risk they are not willing to grant third party developers. So a third party browser/js engine will likely be quite slow. I guess this would give users of a bad impression of iOS perfomance as a whole then, if other browser engines were allowed and became popular?

If other browser engines became very popular it says something about how bad/limited the default offering is. It usually takes a lot of work before people switch away from defaults. People continued to use IE for years for example

Chrome as the sole advertisement on the most valuable piece of web real estate in the universe might have been a factor too.

It's not a security risk (assuming a properly engineered OS).

All OSes have bugs, and the XNU kernel certainly has had its share, so removing the ability to execute arbitrary code definitively makes exploitation of buffer overflows etc in 3rd party apps much harder.

Restricting the JS engine but allowing other browser engines to tie into it so you could leverage different browser's rendering and CSS features would be a step up and would sidestep much of the problem.

Remote execution of code is a very popular attack vector.

Apple can negate this almost entirely by controlling JavascriptCore and WebKit and ensuring that their security models e.g. sandbox are tight and well tested. Leaving that up to third parties who may not be so vigilant compromises the security of the entire device.

1) JavaScript allows for arbitrary code execution

2) Apple’s App Store policies disallow the user from executing arbitrary code

I think you can figure this out yourself.

These are excuses, not valid technical reasons.