Absolutely. I like key-fingerprint-based whitelisting, but I don't like having keys in hashcash stamps. Generating a 25-bit collision on an ~1100 byte hashcash stamp would require nearly 4x the time necessary to generate the same 25-bit collision on a 64 byte stamp. Putting keys in hashcash headers benefits those with insecure keys.
There's no security benefit in putting keys in the hashcash header. If camram really needs keys (or other miscellany) sent in message headers, can it use its own headers rather than bloat hashcash by adding all sorts of options for key transfers?
If camram puts keys in headers, I'll probably pull them out and import them if the message has sufficient postage. And while I can understand why camram might put keys in headers, I don't think headers are a reasonable place to put 700-byte base64-encoded strings. I'm not at all happy about the prospect of those 700-byte strings being in _hashcash_ headers.
1) operates completely peer-to-peer 2) requires no user involvement