All things being equal we would probably prefer to use a single BC for everything. But that is simply not possible for a number of reasons.
First, there is always an ecosystem surrounding any single system, and frequently the system needs to interact with other systems in the ecosystem.
Those other systems are hosted by differing organizations (companies, departments, agencies) with different responsibilities, different motivations and business goals, and possibly different legal/regulatory requirements. Those varied organizations will often want to host their services in their own way independent of the other members of the ecosystem.
Second, splitting a BC into multiple BC's is a method for scaling the system, both in terms of peak load, yet also in terms of facilitating loosely coupled independent parts to foster easier development, evolution, maintenance, and operations. (There are long term advantages to having multiple BC's, but there are also costs in complexity.)
In this particular case, the passenger management may store customer account information, possibly including login/password, payment information (credit card), personal preferences, among other. The system designers may feel that is important data to secure and to develop for fostering and maintaining good customer relations. Logically speaking this customer system is probably a much bigger system than being shown by this one service flow, so it is being treated as an independent BC.
isn't the sole purpose of bounded context to provide higher level of automicity[sic] and avoid BC leave its boundaries in order to serve this solution space?
The primary purpose of the Bounded Context in Domain Driven Design is to provide the context for the modeling of a domain. Each BC hosts a Domain Model that starts with well-defined concepts/terms (vocabulary), their relationships, and their behaviors. Every component or service in the BC should be designed to fit properly into the BC's domain model.
The BC is effectively a unit of contextual and conceptual design, and by extension then, also a sort of unit of implementation (as implementation follows the designs of the domain model). That the BC tends to provide either autonomy or atomicity depending on what you were going for, is more of an natural extension of treating each domain model and its BC as a unit to be implemented, and that within that unit of implementation we expect its sub-components to have tighter couplings than those occurring between BC's.