...a process which could be reviewed as part of the App Store review process.
There isn't really any difference here. If your app reads gyroscope data App Store review will (theoretically!) make sure you're not doing anything nefarious with it. They could just as easily verify whether a browser passes data through correctly.
(I’m aware of what drawbacks result from it, but that’s been explained to death in a thousand replies in a hundred posts about this already, so no need to derail into them here.)
Apple did issue a fix after a few weeks but with no alternative browser engines the only alternative was “don’t use the web on your iPhone”, which is absurd.
Other user benefits might include better performance, more capabilities (it took Apple years to implement WebRTC, for example) and in general more competition that might spur Safari into becoming a better browser.
> What benefits to their users result from that choice?
But now we've gotten to
> I expect a better case will need to be made to convince Apple
Those aren't nearly the same things. Of course it's difficult to convince Apple, it isn't in their interests.
You may choose here to strengthen your argument, but your declaration that it’s hopeless to do so is of no help in that regard. If you wish to continue, I’m willing to listen.
Allowing more browser engines would require granting those engines your battery and gyroscope data in order for them to display per-site permission dialogs.
This problem is unique to browser engines and no other kind of app, as browser engines are uniquely the only kind of app that needs this sort of permissions-granting per-site passthrough.
Apple likely does not consider it interesting or relevant to their users to invest in validating the security models of third-party browser engines for their adherence to App Store standards, nor in providing a public API for third party engines to do so, and so closes off the entire problem space by refusing third-party engines altogether.