The proposal uses trinary version signaling rather than binary signaling. For any particular prospective soft fork upgrade, this allows for three signaling states:
 

* Actively support the change.

* Actively oppose the change.

* Not signaling (neither support or oppose). This is the default state.

Using this additional information, we can release non-contentious upgrades much quicker (with a much lower percent of miners signaling support). For contentious upgrades, miners who oppose the change are incentivized to update their software to a version that can actively signal opposition to the change. The more opposition there is, the higher the threshold necessary to lock in the upgrade. With the parameters I currently recommended in the proposal, this chart shows how much support signaling would be necessary given a particular amount of active opposition signaling:

If literally no one signals opposition, a 60% threshold should be relatively safe because it is a supermajority amount that is unlikely to change significantly very quickly (ie if 60% of miners support the change today, its unlikely that less than a majority of miners would support the change a year or two from now), and if no one is signaling opposition, chances are that the vast majority of the other 40% would also eventually signal support. 

This both gives an incentive for "lazy" miners to upgrade if they actually oppose the change while at the same time allowing these lazy miners to remain lazy without slowing down the soft fork activation much.