I think there are lots of good reasons to make datetimes immutable (e.g. many of the same reasons most languages make strings immutable). But here's one specific to Moment and Luxon: chainable APIs should really always have immutable types because the return value is the thing you use next anyway. When each call returns an instance of the type it's both completely unnecessary and very often harmful for those calls to modify anything.
var a = moment();
console.log("the end of tomorrow is", a.add(1, 'day').endOf('day'));
// do more stuff with a
// oh crap, a is now set to tomorrow? wtf?
If you want a to be the end of tomorrow, all you needed to do was assign a to the whole chain, so this mutation didn't help you. That add() and endOf() return instances of Moment signals that they are Moment -> Moment functions, not mutators that also return the object. A mutable API should have void methods:
var a = moment();
a.add(1, 'day');
a.endOf('day');
// do stuff with a
Dates and times are values by definition, not mutable objects that can be changed via methods. The year 2017 is 2017. It represent a moment in time, or more precisely a period of time between two points. The year 2017 does not “become” 2018 when you .add one year to it. Fully immutable objects are also easier and simpler to compare since they are, again, values. 2017 is 2017, always. Not using proper immutability leads to an “object identity” crisis where everything is anything. An infinite amount of years 2017 are allowed to exist by default(!) and they are not easily comparable or require specific library APIs to allow that.