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
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.
2) Apple has legitimate technical reasons for not allowing other browser engines (well specifically the JS part). Intent matters.