BPM not appropriate here?

Keith Swenson used the example of a major amalgamation to indicate an area where BPM would not be applied in his post Where did I put that major airline merger process definition?
Of course that may be true in that particular case, but it is poor argument for decision-making about how you are to manage a process, or processes in general.
I accept that there are things you just do (let's have lunch today...) and that some things come about despite having no obvious plan or process (UK government, eventually) but dispute the premise that BPM should not be playing a part.
One problem with BPM, is the assumption that the process cannot be changed in flight. It seems entirely reasonable that

1. a process instance should be followed ;
   
2. have a “I’m sorry, Dave. I’m afraid I can’t do that.” moment;
   
3. and be changed at that point.
   

Visualising the state in a BPMN diagram allows a view of what has been followed up to a state and what is expected to follow. The executable BPMN engines of today will struggle with a change to in-flight process instances but there is still plenty of development mileage to run there.

Incidentally, scheduling lunch or any other meeting often does need to follow a process while personal assistants juggle diaries. An advantage of formalising those processes is that all the players understand what is going on and play their part in a choreographed fashion. There are a number of function-specific tools that hide the complexity of process involved in some common activities but that does not mean the disciplines of BPM should be ignored.