The JS Date object is not consistent: there are quirks with its constructor, the JS date is a time object, no sense of time zones beyond one and GMT, absence of daylight savings time, a need for third-party library that is a performance drain. "My problem with Date is that using it means deviating from the fundamental nature of time itself."

The Time is a location in the flow of which events occurs.
Date represents a (readable for human) time

The date object is itself mutable, so it's ok to set a day in place. It can cause unintended side-effects in codebases.

So Temporal comes in. it's a namespace object like Math. There are multiple useful functions, but another magic is in the prototype chain: equals, add, inLeapYear, monthCode.

First, there are plenty of methods and properties devoted to access, format and manipulate the details of the temporal object.
Secondly, "none of these transformations required us to manually spin up any new objects, and that the value of the object referenced by nowTemporal remains unchanged."

Using temporal reduce the boilerplate so much!
Temporal.Now.plainDateISO().add({ days: 1 })

Also Temporal have some time for experimentation.