It's not a straw man argument, it is the argument.
An average user can't dive into the bluetooth driver code and figure out where in the 4000 page spec something deviates and is now a security issue. So we have to assume the worst.
Having an open standard doesn't mean every implementer will do so in good faith and using best practices, the consumer still ultimately has to make a choice about which product they use, and can continue to use apple's solution if they trust in apple to securely implement the spec. The insane strawman you're proposing is that the choice is between a single blessed solution from Apple that's infallible, and a wild west where the only way for a consumer to be safe is to personally audit their device against a 4000 page specification document. Absurd! We use devices and software every day that implement open standards and while issues do arise in particular implementations, they do with no more frequency than issues are discovered in proprietary solutions and standards.
Go look at the CVE's for iMessage, plurality of RCE's on apple devices in the last decade is Apple's iMessage implementation, and it's their own protocol! And almost all of the rest are apple's implementation of the open web standards!
There are maybe three tech companies in the US that have large security groups dealing with persistent threat actors. Apple is one of them. Google is another.
Even with that (large) Apple security group, iMessage is difficult to lock down properly, as you note. However, I think that the cost of 0 day subscriptions for iOS vs Android tell a pretty good story: iOS zero day subscriptions sold to intelligence agencies/governments cost roughly $1mm / seat (phone compromised). Android -- $10k.
There are many many decisions along the way that end up with that raw 100x additional cost for iOS security breaches -- value Apple delivers to its customers when they purchase iOS products.
You cannot pick and choose from the outside and know which of your preferred opening-up implementations would impact that cost. My argument is that opening this up is one of likely hundreds of possible decisions that would contribute to lowering that cost of exploit.
You are just wrong about 0-day values, e.g. exploit vendor crowdfense's publicly offered rewards for mobile 0-days:
SMS/MMS Full Chain Zero Click: from 7 to 9 M USD
Android Zero Click Full Chain: 5 M USD
iOS Zero Click Full Chain: from 5 to 7 M USD
iOS (RCE + SBX): 3,5 M USD
Chrome (RCE + LPE): from 2 to 3 M USDD
Safari (RCE + LPE): from 2,5 to 3,5 M USD
And "large" tech companies despite having "large" security teams (and "large" scope!) are far from the only ones competent at securing devices/software against PTA. Node.js, linux, bsd's, bitcoin, RoR, firefox, curl, etc. etc. There are dozens of open source projects with 0-day values in excess of 7 figures, (and plenty of private enterprises too!) and apple and google are not in any way specially equipped (or better than others) at dealing with the most dangerous PTA's in the world just because they have the largest armies of overpaid EE/CS grads.
I’m past the edit window unfortunately: you’re completely right as far as I can tell.
NSO leaked pricing has not historically differentiated Android or iPhone. I’m not sure where I heard those numbers, but thanks for the correction.
Tiny tiny nit - paying the same for an exploit doesn’t mean you’ll charge the same, but in this case it looks like the value and price structures are what you describe. Sorry!
Slightly less small nit - securing hardware, os and cloud inside some security perimeter model is a lot harder than securing, say, the bitcoin client. So point taken - and, it’s hard at scale, not easy.
An average user can't dive into the bluetooth driver code and figure out where in the 4000 page spec something deviates and is now a security issue. So we have to assume the worst.