Because that way you can use a Date like a value type (that is, share one object in different contexts without the risk that some other context might change it).

Outside of threading, what type of "contexts" are there which could "share objects" with a risk that one of them might change it without it being a deliberate act on the part of the programmer to do so?

And if it is a deliberate act, where is the "risk" you speak of?

Immutable objects also have the nice property of being shareable among threads without need for any locking.

You are basically saying that every object should be immutable, and therefore every mutation of an object should results in the allocation and population of a new instance of the object and the old one garbage collected, even in single-threaded code, in order that on those odd occasions when you need to pass an existing object to another thread, you don't have to copy it.

Copy everything every time you shouldn't have to, so that you don't have to copy the one time you should. Way to go.

And what is the point in sharing a single immutable object anyway? The point of shared data is it allows communication between the sharing threads which is impossible if it is immutable.

I know that the concurrent pure functional languages use this mechanism. But they also have the benefit of separate compilation and huge, often slow, deep analysing compilers to allow them to avoid actually copying & garbage collecting their "immutable" entities when they can safely mutated in-place. Basically, the costs of immutability are optimised away under the covers by the compiler. The purity is language level concept, not a runtime one. I've previously referred to this as smoke & mirrors.

But in a dynamic language, with mutability a fundamental and inherent part of the language design--eg. ++$i etal.--this is a nonsense. Show me one concurrent, dynamic language that has efficient garbage collection?

To make this schema even vaguely efficient, the optimising analysis would have to be done at load-time, and repeated every time the program is loaded. And you'd have to ban eval and all other forms of runtime loading: do, require.

At which point, why bother with a dynamic language?

Sorry, but in the context of Perl, I do not believe that you have thought your immutability arguments through.