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?
Because the idea that all you need to do to ensure software is secure is hire an expensive consultant is ridiculous.
Especially with a web browser which are highly complex pieces of software.
Taking Apple's word for their browser being secure and other browsers not is just as if not even more ridiculous.
What fair, independent way of determining browser security would you suggest be used instead of an audit?
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.
What it does is hold part of the system constant, so that attackers know ahead of time that iOS users will be running WebKit. Reducing variability makes attacks easier and increases the value of WebKit vulnerabilities.
As I said in my comment: I believe Safari and the underlying WebKit to be the most complex and most insecure part of iOS by multiple orders of magnitude.
Not adding more of equally complex and demanding pieces does provide a significant reduction of attack surface
While that's just Safari and Chrome, that's probably ok. But what happens when it's Safari, Chrome, Firefox, Opera, Brave, etc, etc?
For the security test, there are various ways that an org builds software with integrity, and it's the sort of thing that requires a huge amount of effort to get right. Standards like FedRAMP, SOC2, ISO9001, etc etc are the sorts of standardized things that exist (containing things like 'all code must be reviewed'). I think for a browser, if you were Apple and were looking to accept other browser partners, you'd likely do something like this; regular audits of quality, requirements that must be met to maintain access, pentests, basically a continuous process that's to be met by the supplier (similar to how hardware suppliers must meet many requirements).