There's nothing wrong with mutable objects, in fact I've always preferred them. I hope making everything immutable is a fad that passes.
Part of the problem is that moment would both mutate the underlying object and return the object.
const a = moment()
const b = a.add(1, 'second')
Else: a.add(1, ‘second’).add(1, ‘day’).subtract(2, ‘minute’) would create 3 more objects that are not needed. Creating a new moment object is expensive, it happened to me to work with a lib that grew exponentially slow when using above N dates because they where constantly recreating moments instead of using them wisely so creating a new one on every operation would be quite bad.
That’s why the method .clone() exists, so you can declare that explicitly:
const a = moment()
const b = a.clone().add(1, ‘second’)
If `a` is mutated by the `.add()` method, then it should probably return void rather than returning a copy of the object.
Is the immutable DX still better in this specific example? Probably. But the above at least would help developers avoid the major footgun with mutability.
There is tooling around immutability and a whole host of compiler optimizations. The resultant code is far less error prone.
Do you feel the same way about static typing?
There are times for immutability, and times for mutability. You have to be careful for different things.
It's not always the best (or even an) option, but it does spare you some concerns.