Apple's case is a little different because it lets you publish native code on the phone. (You can argue that websites effectively also publish code, but the web sandbox is probably quite a bit stronger than the iOS one.)

I don't think there's much advantage in knowing that you're some registered organization. It's pretty easy to register an organization - see e.g. https://stripe.ian.sh , to which the CASC responded by proposing the rule "Applicants that have been in existence for less than 18 months are not eligible for EV certificates," as well as a requirement that the CA inspect your tax returns to make sure you're a bona-fide business. This is basically a losing game (losing for the CAs, because it won't work, and losing for the world, because startups can't get EV certificates and everyone else loses their privacy), hence my comment about validating that you're a morally upright website. It's the evil bit, except as a TLS extension.

One thing that does have value, though, is making sure a website is the right website. It's perfectly fine for https://stripe.ian.sh to have a cert as long as they don't get my https://stripe.com credentials or cookies. On the cookie side, the browsers already solve this with the same-origin policy, so the hard part is just making sure that you don't enter usable login credentials on the wrong website (i.e., preventing phishing, which is the stated goal of CASC). There are pretty good solutions for this like FIDO/FIDO2 - in the future I'd like to see places like banks either giving you U2F security keys or letting you bring your security key in when you enroll for an account and activate it on their machine, because the FIDO protocol lets the security key participate in the same-origin policy. If I've enrolled my key with bankofamerica.com, and my login requires using a security key, I can't divulge usable credentials to bankofamerica-secure-login-trust-me.com.

Relatedly, the same-origin policy doesn't (and can't) distinguish between the type of HTTPS you have or whether there's a verified organization name on the cert. It treats any HTTPS for the same domain as the same origin. So the browser makers have been pushing back against meaningful distinctions between DV, OV, and EV (and also against EV even having any costmetic distinctions), which is completely at odds with the CASC's strategy. Sucks for the CASC because it means a $0 Let's Encrypt certificate is as meaningful as a $300+ EV certificate, but I think the browser makers are right, here.