The "seat" object though is not connected to knowing "who" is in that seat, only that it is full.

As in "if seat.isoccupied()"

At no time should the passenger object be visible to perform a new booking. I see where you might need it if you are changing a reservation, but again this shouldn't in any way be linked to the passenger manifest.

Maybe they want to be able to verify, across multiple sessions, that multiple seats aren't occupied by the same person, or to potentially be able to visually indicate that someone has multiple seats.

Obviously you can easily design a schema that does that without including the names of other passengers, but that schema would be idiosyncratic to that one purpose.

Which leads to: why in the hell does your schema allow for a passenger to occupy more than one seat at a time?

It doesn't. You, for instance, accidentally book the same flight twice, or your company's travel person does.

Frequent-flyer perks.

Given a certain level with the airline, United for example blocks the seat right next to you to offer you extra space (this can be overruled if the plane gets too packed). Thus, one passenger may be linked to more than one seat.

Some people don't fit in a single seat?

Wouldn't that be better accomplished with two passengers with the same name? You aren't getting that second seat for free! :-)

What happens if the two seats aren't adjacent? :O

Then at least that passenger wouldn't be much more uncomfortable than he'd be under the present system.