Microsoft is shortly coming out with some documentation on SenderID and the business case for its implementation. Hopefully by now I have demonstrated its usefulness.
The Purported Responsible Address has a couple of advantages when deciding to support SenderID vs SPF:
The MAIL FROM has the following advantages:
Both techniques can use the same SPF record format, though with SenderID the implementers need to know what they are doing since SPF classic was originally designed to be used on the envelope sender domain.
For SenderID, if the PRA chooses one of the Resent-* headers, then it will not be the identity typically seen by users and help detect phishing. In that case, SenderID could be used to help phishing, not deter it.
This case needs to be handled. It seems like SenderID needs a SSP doc like DKIM that allows domain owners to say they allow 3rd parties to ues their Domain in RFC822From. But I don't even like that idea because it will most likely end up being to permissive like SPF's ~all.
That's true enough, though I think that the Resent-* headers are intended to be used for forwarders and SenderID will extract that domain in order to prevent false positives.
This speculations about "the identity typically seen by users" is slightly nonsensical when it comes to compare techniques not used on average. If any of that stuff will ever become relevant, client software will upgrade.