Why don't PGP keyservers enforce double-opt-in?

Key servers may never be understood as a source of trust and valid keys. Their only job is to exchange keys, so users of OpenPGP can use the web of trust formed by certifications between keys to validate trusted ones.

Access to a Mail Address Does not Imply Impersonation

Trusting a key is (for most people) more than just verifying a mail address once. Mail addresses tend to change, to invalidate, even to be assigned again afterwards.

Validating an email address based on trust would require some form of invalidation, eg. removal. But how should for example a revocation or other changes be distributed afterwards?

Some Key Servers Do!

But, there are key servers doing so, and thus take the role of a certification authority. Ever wondered about certifications issued by the PGP Global Directory Verification Key? These are issued by the PGP Global Directory Service after validating the mail address contained in a UID, will invalidate after a given time without re-approval (six months, if I remember correctly) and your key will be removed from the server if the certification expired.

But remember: this key server is different from the others, as it offers a very basic authentication of key ownership, but does not support the OpenPGP "way" to validate keys using the web of trust.

How to Define Valid Keys?

As there is no central "trust institution", no certificate authority (or even not several hundred of them, as in X.509); who should define whom to trust? The key server operator? This would at best reduce the number of available keys by order of magnitude, in fact possibly to a few dozen or hundred trusted keys of the operator, compared with millions of keys mostly not even connected to the OpenPGP web of trust.

Additionally, each OpenPGP users potentially has his own rules to decide how to validate keys, although these might be rather similar most of the time.

Key servers simply form a method to exchange data between OpenPGP clients. and usually do not take the role of a certification authority.

Key Servers Synchronize

Most key servers synchronize with each other. Already the ones listed in the SKS key server pool list about two hundred of them, most of them operated by individuals who even don't know each other.

Having such a decentralized key server infrastructure is crucial against several attacks (denial of service, deletion of keys, having a central log of what's requested), especially from those having access to large portions of a network (ISPs, governments).

But: how should email address verification be achieved in such a distributed network of unrelated servers not trusting each other? The only possibility (at least, no other was proposed so far) is to replicate everything, and each key server would have to decide on the validity.

Would you like to approve each of your mail addresses to 200+ key servers in given (and very likely different and rather short) time intervals?

It's very important to understand that OpenPGP keyservers are not certificate authorities. They are not responsible for key verification. OpenPGP employs a decentralized trust model, so it's the user's job to verify a key either by directly checking the fingerprint or by using the web of trust (like you already said).

When people use keyservers to download a key for a given e-mail address without any further validation, they fundamentally misunderstand the trust model of OpenPGP. That's not the keyserver's fault.

Of course keyservers could introduce basic verification to reduce to amount of garbage keys. However, this would further blur the line between keyservers and CAs, and it might create a false sense of security. The fact that somebody was able to read a link within an unencrypted confirmation e-mail doesn't prove anything, because the e-mail may very well have been captured in transit. So a keyserver offering “verified keys” based on this method would be walking on thin ice.

The purpose of key signing parties is not to check e-mail addresses. As the name already implies, they are about keys. To be exact: Typically, a participant A checks the identity of another participant B, asks for B's fingerprint and then signs the corresponding key. So if I want to communicate with B and already trust A, I may use that signed key. Of course B might lie and provide a false e-mail address, but that's a social issue, not a technical one. If a person just refuses to have a private e-mail conversation, no protocol will fix that.