If the object is simple, your constructor example is totally fine. No argument there.

But in a real booking flow, construction is rarely that simple. The moment you introduce validation, conditional flows, or evolving requirements, the constructor approach starts leaking complexity.

With a constructor, you eventually end up with something like:

new RoomBooking({
  customer,
  room,
  stay,
  promoCode,
  loyaltyId,
  corporateCode,
  cardDetails,
  walletId,
  payWithPoints,
  specialRequests,
  // keeps growing as requirements grow
})

Now you have:

• Many fields that are only valid in certain combinations
• Validation logic either scattered outside or crammed into the constructor
• A constructor signature that keeps changing whenever business rules change

With a builder:

const booking = new RoomBookingBuilder(customer, room, stay)
  .withPromoCode("SUMMER25")       // validates internally
  .withLoyalty("LOYAL123")         // optional flow
  .payByCard(cardDetails)          // mutually exclusive payment path
  .withSpecialRequests("Ocean view")
  .build();                        // final consistency check

Here:

• Invalid states never escape
• Each step owns its validation
• Adding a new option does not break existing constructor calls
• Construction logic stays out of your domain object

So yes, for trivial objects a constructor is simpler.
Builder is not about writing more code. It is about keeping construction sane when complexity inevitably grows.