But seriously, I think that's the actual answer. The only way you find websites is by receiving a URL from somewhere - whether that's from a search engine, or from a link on some other website, or from non-web means like a paper advertisement or a billboard. And the PKI does solve the problem of bootstrapping trust from a textual URL. (And to be actually fair to Google, they've HSTS-preloaded the top-level domain .app, so any website inside .app gets HSTS from first use onwards - which seems like the right way to solve the problem of URLs communicated aurally.)
To solve the problem of "Am I on the right website," the concept of "right website" has to be well-defined - which generally means you have to already know of the existence of some right website. The UX problem in security is how to take advantage of that knowledge, e.g., not let a Bank of America customer click a link in a phishing email that doesn't actually go to the website they previously signed up with.
The alternative is that some committee like the CASC determines which sites are morally upright and worth anyone visiting, and which ones aren't. That solution works okay for physical sites, more or less, but applying it to the internet generally doesn't produce good outcomes.
Personally, I would not be opposed to CAs requiring proof of cyber insurance in order to issue an EV cert.
If someone is offering that today, they aren't marketing it well. And again, actually signing the certificates would be a negligible part of the business (or the cost).
Actually, if I were in the insurance business I'd actually think about pushing this direction. If you could get the browsers to sign up for giving it special treatment it would probably greatly increase the size of the market. (Right now operators seem to mostly just escape significant liability for compromises)
The human who may be sat at a PC using, say, a web browser, can contemplate anything they like about a certificate and, in principle has some very sophisticated tools at their disposal, for example a human _could_ read the name "Fun Co. Jurassic Toys Inc." in the Subject O field of a certificate and think about a TV documentary they saw last week which said this company was run by a convicted fraudster from Spain, and that might colour their opinion of the web site they thought was a legitimate discount airfare company named "Cheaper Flights" they'd seen recommended on Facebook. They might ask their IT literate nephew Steve, "Hey, Steve, one moment, does this site look dodgy to you?" and end up not giving a criminal $850 for tickets to San Francisco that never existed.
The software, a Web Browser or similar User Agent software, is not capable of such sophisticated insight. But unlike a human its mindless checks are done for every single resource in every single page. That GIF in the top left corner, the CSS stylesheet, the Javascript auto-scroll, since it isn't thinking it doesn't get bored and skip things or take short cuts.
All trusted certs, including DV certs, allow the software to do all its checks, in real time, as it proceeds. When you submit a form by pressing the "reply" button on Hacker News to insist I'm wrong, your browser will insist on verifying that it is posting that reply to a server which has the appropriate credentials for news.ycombinator.com before it transmits the reply, not a minute afterwards when it's too late. This simple, entirely automatic, verification is the only way to make it painless enough to actually get used. Any security strategy that says "And then obviously the human operator does X" is from a dreamworld unrelated to ours, a world which also has no drink driving, nothing is ever left in the back of a cab, a world where the pencil eraser was never invented.
If the browser vendors had wanted EV to have a practical impact on the actual security, rather than just the cosmetics desired by the CA industry's sales people, they'd have instigated a more complicated origin policy, but they intentionally didn't do that.
If your situation really is that your sites mostly attract visitors who genuinely had no previous connection, nothing we can do fixes the actual problem, you are asking merely for theatre, which will cost you extra money, in the foolish belief that conmen aren't going to also put on a show, and probably a better one than you, if it makes them money.
If you can count on a prior relationship in encryption, then you don't even really need PKI. Just mutually decide on an encryption key and then use that to encrypt/decrypt your traffic.
Not every website is Twitter or Facebook or Google or a major bank, where the vast majority of visits are repeat visitors. I run dozens of websites, and every single one has more than 50% new visitors, year in and year out. That is representative of the vast majority of websites out there.
Browser makers have dramatically shifted their security focus toward repeat visitors. Two-factor authentication, same-origin policy, HSTS, and other new security features are only useful for repeat visitors.
EV certificate notices (the "green banner" in the address bar) are one of the very few browser features that attempt to help first-time site visitors. Now, obviously EV certs have problems as you cite with Stripe... but instead of trying to solve this problem, browser makers are simply copping out and falling back on a posture that HTTPS just means encrypted over the wire, not identity. Essentially: establishing security is the user's problem. Once it's established, then we've got all sorts of tools to maintain it.
This is a mistake. It does not help most websites, and it privileges incumbent services (which have lots of repeat visitors) over new websites (who are trying to win new customers).
CAs and browser makers must continue to attack the problem of trust on first visit. It's not an easy problem but it is the essence of the promise of the web. Visitors should be able to load a new site and know if it is trustworthy, just like people trust that they can physically walk into a new store and not get robbed.