In other words, I remember faxing data into verisign or thawte back in the day (not even that long ago), but OV is just not worth paying for anymore: OV provides zero value, now that DV certs are accessible. Someone who had access to your domain could just get a DV (or LE) cert and no one would be the wiser.
I'm not sad to say that Comodo wrote their own death certificate (ha) by racing to the bottom. It's hard to beat free and open source.. the only thing they've got to hold onto now is EV, and that's of diminishing value now as well.
The Baseline Requirements require certificate authorities to be able to verify the correctness of the information that they include in each certificate -- including for DV. See the first subsections of section 3.2.2 of
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-...
It's kind of crazy, actually: it's more expensive for you to prove who you are than it is for the attacker to NOT prove who they are. Security should be about raising costs for the attacker, not lowering them!
And, as you know, neither Let's Encrypt or any other DV CA's check or verify any information except control of the domain itself.
That's why those certs are called Domain Validated instead of Org Validated ;)
The broader point is that whether that metadata is visible or not is what renders the OV to be the same literal value as a DV; even to a security-minded audience, an OV provides literally no extra value over a DV to the website's audience/customers, because it's effectively invisible. And EV does, on some browsers, but the positive benefits of EV are diminishing.
And because OV ~ DV to its users, the security value of OV over DV is nil; they are interchangeable for the purposes of protecting a website.
They might have more value, depending on the app, on other protocols, but for HTTPS, browsers have effectively rendered them identical.
If you submit a CSR with any of these fields, and you're requesting a DV certificate, the CA will discard those fields. Any sane CA implementation will cherry-pick only a whitelisted set of fields from the CSR, make sure the values have been validated according to the Baseline Requirements and root policies, assemble the certificate from that data and sign the result, ignoring all other fields (or discarding the request).
CAs that run something like sign(user_submitted_csr) would not last long in any of the major root programs.
I don't know if every DV CA does this, but I got a couple of StartSSL's free certs a while back (before LE was around, and before the WoSign acquisition and subsequent debacle), and I recall the documentation saying "because this is a DV cert, we're just going to ignore all the metadata in your CSR and generate a certificate with those fields blank", or something along those lines.
Value in terms of cost, or in terms of utility? And if the latter, care to explain why? I know almost nothing on the business/political side of certificates.