From the article:

    const now = new Date();

    const now = Temporal.Now.zonedDateTimeISO();

I mean, I guess it's two steps forward and one step back ... but couldn't they have come up with something that was just two steps forward, and none back ... instead of making us write this nightmare all over the place?

Why not?

    const now = DateTime();

I think that it's nice it's explicit that the method returns the current instant, rather than some other zero value.

There's also other methods that return other types, like

    const now = Temporal.Now.instant()

One could argue that the ugliness of the API intentionally reveals the ugliness of datetime. It forces you to really think about what you mean when you want "the current date time," which I think is one of the goals of the API.

Firstly, I really want this also and am supportive of an opinionated decision to put something at say Temporal.DateTime() that would be logical for developers to use ‘most of the time’.

However my guess is that the spec designers saw this lack of specivity as part of the problem.

A key issue of dates and times is that we use them culturally in day to day use in very imprecise ways and much is inferred from the context of use.

The concepts of zoned time and “wall clock” time are irreducable and it’s likely much code will be improved by forcing the developer to be explicit with the form of time they want to use and need for their particular use case.

I think this is why it’s so explicitly specified right now.

But I agree; I’ve often struggled with how verbose js can be.

Maybe with time (pun intended), more syntactic sugar and shorter conventions can be added to expand what has been an incredible effort to fix deep rooted issues.

If you give me your background I'll explain in longer terms but in short it's about making the intent clear and anyone who understands s modicum of PL theory understands why what's a constant is so and what's a function is so.