Rick: Excellent, thoughtful question!
I am not a Sovrin spokesman, but I’ve participated in many Sovrin design debates, so I’ll answer from my own perspective and let you decide how well it embodies Sovrin philosophy…
First, I’d revise your first “potential disadvantage” paragraph by saying that the words “In the extreme case” should be replaced with “in the common case, virtually guaranteed to occur”. Privacy loss isn’t potential or theoretical, unless you believe that the Facebook debacle was surprising.
Second, I think your connection later down between pairwise DIDs and “trust-on-first-use” gets to the heart of a misunderstanding. DIDs aren’t supposed to be trusted (in the way I think you assume) because of either their DID value or the keys associated with it. Just because Acme’s website announces to the world that “we do business as DID 12345” doesn’t mean the world should believe it. The website could be hacked at any time. Current PKI that uses X509 certificates assumes that a website is legit if the certificate is provided by the server when the client browses there–but we all know of many cases where hackers take over a site and change content while leaving the cert in place.
Thus, the potential disadvantage you point out for pairwise DIDs isn’t really unique to pairwise DIDs. No DID is trustworthy just because it exists and is backed by a key–not even public ones. DIDs are trustworthy because of what the person on the other side of the connection can prove about themselves, using verifiable credentials and the proofs that derive from them. This is what’s radically different between Sovrin and WhatsApp–the latter doesn’t propose to prove anything, once the encrypted channel is set up. You’re just supposed to trust because of key possession itself (plus WhatsApp’s endorsement of the other party’s contact info, maybe). What the other party says over that encrypted channel can only be assumed to be true.
Sovrin’s proving mechanism is far, far more powerful and flexible than certificates. For example, you can steal a person’s private keys for a DID and still not be able to prove things as them (impersonation), due to a link secret and agent M of N authorizations. You can even steal private keys plus a link secret, and still not be able to impersonate, due to an AuthZ policy. Sovrin supports various recovery mechanisms and revocation mechanism that are way more powerful and privacy-preserving than the familiar and justly maligned cert revocation mechanisms of PKI. This is the DKMS design work you may have heard about, that was developed under a research grant from the US Department of Homeland Security, and that is explorable here until it moves into a more permanent place in Indy or Sovrin: https://github.com/evernym/protocol/blob/master/dkms/DKMS%20Design%20and%20Architecture%20V3.md.
Pairwise DIDs would significantly increase traffic to the ledger, if they were stored there. But they will be stored in micoledgers instead. Microledgers are also discussed in the link above; they have been announced as a Sovrin feature but are not yet in production. Even without microledgers, Sovrin’s ledger would be able to support pairwise DIDs, however, for many years to come.