Yes, it allows a vendor to "prove" they fixed a vulnerability. Perhaps if you're looking at vulnerability research as an outsider you think this is a significant issue. But it really isn't. If Chris Valasek or Tavis Ormandy say that (say) Adobe hasn't fixed their finding, everybody (including Adobe) will believe them. On the flip side, when Adobe fixes Valasek or Ormandy's bug, they're going to say that right away. Believe it or not, vulnerability researchers like it when vendors fix their bugs; it's part of how you keep score.
And even if you think proving vulnerabilities is a real issue, all this does is allow vendors to decide autonomously to prove something. But vendors don't need tools to do this, and neither do researchers. The real problem is that vendors sit on vulnerabilities for months or years; giving them one more (complicated) way to publish doesn't really help much. Meanwhile, the researcher can disclose any time she wants; she justs posts the exploit to Pastie or F-D. Done and done.
And yes, this creates a central location for customers to see outstanding security issues with products. But Zed can do that right now without getting researchers to do anything differently. He can just follow security researchers on Twitter and RSS their blogs and wait for them to post things. Then he can create entries on his site. Charlie Miller even posts numbers, like, "I have 193882 binned crashes in Quicktime and Apple has fixed none of them so far". Some visualization tools might come in handy. It's less fun than crypto schemes, but probably more useful.
Also worth mentioning: there already are "vulnerability arbitration centers" that do exactly this. Also, they take over the project management with the vendor. Also, they publish formal advisories to alert the public. Also, they pay the researchers. Sometimes a lot. One of them is TippingPoint's Zero Day Initiative, which also runs the annual Pwn2Own contest at CanSecWest. Another is iDefense.
Finally, you can consider whether this addresses the problem of "how do I communicate a vulnerability securely to a vendor". That is indeed a real problem and this is indeed a viable answer to that problem. But every vendor that has a vulnerability response process already has a secure channel for receiving reports. From spending the last 5+ years of my life communicating findings to vendors who don't have that process in place, let me assure you that "secure channel" is the least of your problems. Forget getting your email intercepted; worry more that your finding is going to end up in the vendor's public bug database tagged as a "feature" (seriously, go pick a slightly non-mainstream vendor with a public database and do searches for "segmentation fault" or even "nessus", as in "bug: product crashes and reboots when nessus is run against it").
---
If, as a vendor, you want to do something to streamline vulnerability reports, run - do - not - walk to create this web page on your site:
http://news.ycombinator.com/item?id=804257
I highly recommend you just crib from what 37signals did.
If you don't, and rely instead on the notion that a researcher could in theory use the RSA key in your SSL cert to send you a secure message, please bear in mind that many --- perhaps most --- researchers will interpret your lack of guidance on this as a license to simply publish your flaws directly on a mailing list. You didn't, after all, tell them not to, or tell them where they should instead send their findings.