Well, if the domain was a phishing one (https://stripe-support.com) and had an EV certificate for Stripe Inc., it would have had a similar effect on trustworthiness in any browser.
I don't doubt that EV could be automated for many jurisdictions, even without amending the current Acceptable Methods of Verification.
OID 2.5.4 could easily introduce a new element companyRegistrationUrl and all new EV certificates would be required to include it. Then, the browser could display that information along with the existing subject information (country, company name, etc). That's the essence of your proposal, right?
I think that's fine, it's an incremental improvement to see that info in the browser (even though 99% of users would never even bother to check it. Peter Guttman's book draft from a few years back Engineering Security talks about this a fair bit, even if you only read the chapter PKI-Me-Harder).
I'm not sure that it would be a meaningful improvement, though. As danb35's article wrote, users never notice when a certificate is downgraded from EV to DV. What is one to do? Companies start having to publish DNS records that their domains can't be accessed over DV-certificate domains? How do you publish such a policy for an infinite variation of hypothetical phishing domains? Do we just do away with DV entirely? (no). How does DV co-exist with EV if it's technologically impossible to make a real-life entity "EV-strict"?
There's some kind of UI/user education/CA policy/technological equilibrium where the Web PKI actually makes sense, but honestly I think we should be quickly moving away from the notion is "this site is trustworthy" and downgrading the rhetoric to "this connection is not intercepted/this transport is secure", since that's all that HTTPS can realistically hope to achieve.