Systems that are choreographed are loosely coupled, highly flexible, and easily amenable to changes (internal as well as external). As an example, let's consider an order application. Using the reactive architecture (event-driven choreography), the flow can be represented as follows (this is taken from https://blog.bernd-ruecker.com/why-service-collaboration-needs-choreography-and-orchestration-239c4f9700fa):

The payment service is destined to react to the order-placed event. The issue here is that the payment service has to know its consumer. If any other service needs the payment service, we need to make the changes in the payment service. Now, there's a new addition in the business requirement. The addition is that VIP customers can pay later by invoice. This change is to affect multiple components. The payment service has to execute payments for non-VIP customers only.

The inventory service also has to react on the order-placed event, but only for VIP customers. The following diagram explains this process:

This requires the introduction of an additional component that brings in a clear separation between Service A and its users. This is called the event-command-transformation pattern:

The event-command-transformation pattern is ultimately helping to realize decoupled event-based systems.

The second hurdle is that the payment service might take longer to complete. Customers have to clear their payments and this may take days or weeks. This is a long-running process flow and it's mandatory to track the state. It clearly bats for an orchestrated style of collaboration. Hence, the blending of orchestration and choreography is the best way for pitching in highly flexible architecture for composite applications.