I think it’s a classic RPC vs orchestration vs choreography decision making.
With RPC, you can ask a service to do something for you and get the response. You either get what you want or not. It is full coupling in time in space and those that call the service need to conform unless it’s an Open-Host, which is a sort of conformity nonetheless.
If you decide your services to express reactive behaviour, you need to deal with asynchronous failures within a given SLA and introduce an intimate relationship between event producers and event consumers, unless you decide to use the Interchange Language context, or your language is so generic that you can use the Published Language pattern.
However, not always understanding the language of another context requires conformity. Like we translate languages from one to another, context languages can be translated.
Orchestration, although harder to implement, makes total sense in some cases, when the process requires parallelisation and some execution logic, based on the message flow. In the carpool example, it might be a good choice. Consume the ServiceRequired event and send the ScheduleCheckOut command. Provide a method in the carpool context to override the denial, because check-out requests can be urgent. Deal with denials and scheduling in the process manager. Handle the schedule changes based on urgent requests in the carpool context (it will be needed anyway, for various reasons).
It can be like a drug. Since long processes are everywhere around us, it can be hard not to try implementing this pattern everywhere. But, in most cases, just letting thing flow is easier and more natural.
The main point, I suppose, is not to demonstrate some ways to reduce coupling. Modellers need to pursue decoupling, realising and embracing the necessary coupling at the same time. Moving from Conformist or Partnership to Customer-Supplier, Open-Host, Published Language, or ACL is desirable. But it might not be always practical, so decoupling for a sake of decoupling should never be the goal on its own.