I think that the article's defense of immutability is a bit poor. Making a date mutable means that it won't always reference the same point in time: yeah, a birthday will remain constant, but an appointment may not; the same goes for a lot of types. That's why C and C++ gives us the "const" keyword: the same object can now be used as mutable or immutable, depending on circumstances.
The other points, especially the second, are spot on, although they have a lot more to do with the Java culture than with the language itself.
The date of an appointment might change, but the date itself does not. Dates are values that refer to a fixed period of time; the meaning of "March 7th 2013" won't change if I move an appointment.
The correct way to handle an appointment is to have a reference to an immutable date. When you want to change the date the appointment is on, you change the reference to a different date, not the date itself.
You are thinking about both dates and appointments the wrong way. Dates never change, they are fixed points in time. A date is not an appointment; an appointment has a date associated with it, and many other things. Appointments do not change either: they are canceled and rescheduled (which means making a new appointment).
The problem with C and C++ having the const keyword is that it is overly restrictive and is not flexible enough. What you are trying to express with const is that the value of an object before a computation is equivalent to its value after the computation, under some definition of equivalence. What const actually says is that the object will not change at all. C++ tries to mitigate this with mutable, but this is too rigid: the same things are mutable or immutable regardless of the context.
What we really need is what you see in specification languages: the ability to declare precisely how a value is modified by an operation. Maybe I have an object with a stream member, and I want to say that nothing will be written to the stream without saying that the stream will not flush its buffer for one operation, whereas in another operation I want to ensure that the buffer will not be flushed.
The other points, especially the second, are spot on, although they have a lot more to do with the Java culture than with the language itself.