On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

2) The risk of an old full node wallet accepting a transaction whose
coins passed through a script that depends on the softforked rules.

There's that, but there's also a case where an attacker creates a majority chain that follows the old rules but not the new ones. Non-upgraded nodes would accept a transaction on what they believe to be the consensus chain only to find that when they try to spend those coins no one accepts them because they were part of an invalid chain.

This has the effect of dropping non upgraded nodes to a form of spv security without their consent.

This is in contrast to a hard fork where a full node operator could explicitly set their node to accept higher version blocks that it can't validate. They get the soft fork functionality back but they have at least consented to it rather than have it forced on them. Doing forks that way would also have the benefit of notifying the user they are accepting unvalidated coins, whereas they wont know that in a soft fork.