I think that just having more than one pool within a BPMN diagram is not enough to consider it as choreography. My feeling: the difference between orchestration-dominant and choreography-dominant processes is in their behaviour. The former have “globally predictable” behaviour. The logic of templates (one pool implies one instance) is enough to implement such processes.
Diagram below (process for “selection of the best offer”, optimistic case) I would consider as choreography – its behaviour is less predictable. The logic of instances is required, because pool “VENDOR” actually implies many instances (one per each vendor involved in a bid).
Of course, in BPMN all vendors operate in the same way and that is perfect from the point of view of the company (i.e. pool “COOR”), because the company has to prove that all vendors are treated equally. In some sense, pool “VENDOR” acts as vendor’s proxy (or insulation layer). This allows us to make such coordination more explicit (easier to validate, control, monitor, certify, etc.)