It's not that they're one judgment away from that day. They know that. It's just that they want to get as much mileage as they can before they too abandon Safari and first allow, then switch to Chromium. That will happen in the next 5 years.
What might come of it all would be a reset where new branches form and new innovators get to introduce new proposals. Standards aren't a bad thing if they're open. If Safari dies then Google will be next in the line of fire for antitrust action anyway... things will fragment again. I'm personally pissed at the number of great technologies left as litter along the road, not least AS3, just to get to this shitty middle ground / cold browser war between two companies I hope die and one that won't help itself. Let the standards win and let's have a standard platform to innovate on top of.
That's one reason, but not the only reason. Security is another big one in that the WebKit process is running with privileges that Apple does not want to award to any other app process on the platform, much less a third-party one.
They also want to make sure that if they fix the next security flaw what will undoubtedly be reported in WebKit, that all the apps with an embedded browser will get the fix and won't continue to be vulnerable due to them not updating whatever version of Chromium they were embedding.
Of course, between sandboxing and not allowing JIT compilation, those vulnerabilities couldn't do do much harm, but that embedded Chromium also wouldn't be much fun to use.
Which means, if you let me make a prediction of the future, that when Apple is forced into allowing other browser engines, articles will be written about how Apple is complying by the letter of the law but not the spirit by "seriously hampering 3rd party engines" compared to their own by now allowing JIT compilation.
If they had to then also allow those 3rd party engines to do JIT compilation and bypass the sandbox in means that browser engines need to, then we'll be in a much worse position security wise.
We'll see how this is going to play out, but I'm pretty sure exerting control is not the only reason for Apples' stance.
If they really cared about security then they could subject their browser to an independent security audit, and require the same audit be passed for any other browser that's allowed on their platform.
Why don't they do this?
As it stands now, WebKit and the processes hosting it (Safari, WKWebView) are probably the most complex piece of software running on our iOS devices and as we can see, they are full of security flaws.
But so are the engines of all other browser makers.
Audits is not what uncovers security flaws. Detailed research, fuzzing and effectively unlimited time to do both on the side of white-hat hackers and unlimited budget and criminal energy on the side of black-hats is what does.
Same is true for other engines of course.
But being restricted to a single engine shipped and updated as part of the OS with tailor-made support by the OS for sandboxing and JIT restrictions for this one engine does help to reduce attack surface.
Also, my initial concern isn't as much about third parties shipping their browsers (though, consider how many third party browsers exist and how many are well-maintained), but much more about apps embedding a vulnerable version of an engine and never updating it ("it works fine for us - no need to change a running system")
Audits aren't supposed to be an ultimate guarantee of security, but provide a minimum, independently judged hurdle that has to be passed to get on the platform.
If there's a better, independent way to judge what browsers are "secure enough" to be on the platform (ie. not just "Apple says no"), I'd love to hear about it.
Minimize attack surface, minimize choice.