Probably because Apple is very concerned about providing a secure experience for their customers. By requiring that all app developers use Nitro they can rest assured that those apps are at least as secure as mobile safari when it comes to browsing the web. If Google was use their own JIT compiler in Chrome for iOS and there was some serious security exploit that affected users as a result do you think users would blame Apple or Google? As far as most non-technical users are concerned, they would likely blame Apple because that's who they bought the phone from.
There is competition in software, btw. You can buy an Android or Windows phone and get a completely different web browser in them.
That's what the app sandbox is for. As long as the sandbox holds up, it doesn't matter what security vulnerabilities are in the app within. And if the sandbox doesn't hold up, you've probably lost the game regardless. There's plenty of room for security vulnerabilities in an app like Chrome even if they're not using a custom browser engine.
App sandbox is just one layer of the security model that iOS employs, and another is not allowing JIT'd code, in case someone finds a way to drop a payload into W&X memory. There's no reason to increase your attack surface if you don't need to.
Is the restriction on JITs really a security thing? That seems so completely far out there on the list of concerns compared to common stuff like buffer overflows which Apple does pretty much nothing to prevent. It always looked to me to be a technological means of enforcing their rule that you weren't allowed to download new code to run (on purpose).
It's very much a security thing, there've been lots of exploits that work by dropping a payload into a W&X marked area in browsers (usually dropped in by buffer overflows).
Apple also doesn't like unsigned code, and JIT (or self modifying code, or whatever falls into that category) is inherently unsigned code.
Forcing the use of a single rendering engines also minimizes memory usage (the code for the engine can be mapped in shared memory) and thus allows Apple to ship devices with less RAM, slightly decreasing power usage. It also speeds up the launching of applications that use a renderer (the code for the browser, its JavaScript engine, the font renderer, etc. will already be in memory)
I think that effect could be fairly large if Apple would allow applications to contain their own web engine, not because it would mean a second engine, but because it easily could mean a third, fourth, etc. engine, given that not all applications get updates at the same time. Imagine app #1 shipping with Firefox's webview version X, app #2 Firefox version X with bug fix Y, app #3 with Firefox version Y, etc.
Apple allows Unity and Unreal Engine, all of which are just as big if not bigger than WebKit. Leaving the realm of games, they also allow Mono/Xamarin, which is a similarly enormous framework.
The restriction is plainly a business decision, not a technical one.
