This anitpattern is almost trivial. Yet watching how different people make the same mistake at different projects I come to conclusion that it’s quite popular 
Example 1: Concluding a contract. The draft must must be signed on behalf of our company by CEO:
Please respect the boss by giving him the opportunity not to sign the contract - put the gateway immediately after “sign by the CEO” activity.
Example 2: while processing a customer’s order, an agent company places an order with a partner:
Recognize that the partner has a free will and take into account the the possibility that he will not accept our order - add the gateway to the process.
One-way modeling is OK at early stages of process discovery, it’s the so-called “happy path”. On the other hand, is there any activity with the predetermined outcome? Maybe it’s better to check the result after each and every activity?
Putting gateways everywhere will clutter the scheme. The lesson learned from this antipattern is this: as a minimum, put the checks after activities where the free will is clearly visible - for example, assigned to decision makers or organizations independent of our.
I think this example touches on a problem with the design of BPMN notation when you apply it to the field of Human BPM. Both of your example are human “facilitator” diagrams. Making decisions is an inherent part of most human activities, or at least most knowledge worker activities. Like you point out, people can always decide not to do something. Some shallow minded individual will claim that the process should “force” them to do it, but anyone who examines the problem will see that there exist situations that it is the right and correct thing to decline to do the action.
This anti-pattern is a good one, and I would suggest that in order to design a system to avoid this problem would be to represent every activity as both an activity and decision. Note that a decision is not the same thing as a branch. A decision is made by a person, and usually, but not always, corresponds to a branch. I wrote this up here:
http://kswenson.wordpress.com/2009/04/06/representing-choice-in-a-process-diagram/
The current designers of BPMN are not thinking about people doing the actions, but instead each activity is just a call to a service. Services are not flexible like people, and don’t really, as you put it, have free will. Thus BPMN is not designed to make it easy to avoid this antipattern.
I have to agree that it is shocking how often then “No” case is overlooked. Especially when estimating a process build-out. Because the happy path is less expensive to implement than the “no” path. It isn’t as simple as “No.” - usually when the VP says no, the submitter/requestor has an opportunity to redress any concerns and re-apply. Then you enter questions as to how many roundtrips should be allowed- and if there are two approvers in the chain, does any change force re-approval by both approvers or only the one who had previously rejected the proposal? The logic can be a little convoluted to get through with the business, but it is work that has to be sorted out!