Not really, as a did:web identifier (or did:ap:web counterpart) could just naturally be resolved on it’s own. I’m saying of having well-known keyservers that key-based identities can be published to, in order to assist resolution of did:ap:key identities in the beginning, such as if implementations choose to avoid the overhead of the aliases being codified into the DID (or if the mentioned servers are gone). At least, it can be “training wheels” to let people start poking with portable objects before they have a full implementation, maybe.
As for did:ap:web, it might not be worth distinguishing a separate ActivityPub-specific DID counterpart to did:web, if the server provides the JSON-LD representation of the actor when application/did+ld+json is requested. Thankfully an ActivityPub actor can also be a valid DID document at the same time, so did:ap:web might not even be needed.
Also with did:ap:key, I don’t know if it’d be worth prototyping another method, such as something that allows key rotation (sign and hash-based with JCS instead of DAG-CBOR); or just roll that into did:ap:key instead, as it’s a separate [experimental] identifier that isn’t necessarily “set in stone” yet.
Nonetheless, I think most of the work now should be just prototyping actual implementations of FEP-ef61, and experimenting with variations from it, to see what the most appropriate path to take is (aliases in DID or not, envelope or not, etc). Some of the discussion is just dragging out hypotheticals of ‘how it could be done’ and ‘how it can work’, when these things should be decided by field testing some experiments. I guess I’ll just jump ahead and try to get a complete working implementation first, then start arguing for a particular path.