Unix has been around for longer than Windows has with fewer changes to basic things such as this. While this is a poor measure of correctness, I think it says something.

It says something. Quite what it says is open to question.

Of course the behaviour makes sense to Unix heads familiar with how the C rename() operates. Which is a plus. Less to learn.

Apart from this, and being simple to implement, is it a good decision?

demerphq says that it's "much more common to want to rename things and overwrite what was there before". This is reasonable, but (after a quick grep of the Perl I have laying around) it doesn't match my experience.

The current behaviour certainly makes coding some operations harder. If rename failed if the new filename existed we could do:

rename( $old, $new ) || die $!;
[download]

and be certain that $new won't be damaged if it already exists. However, with the current behaviour we either have to abandon rename completely and spend a lot of time and effort doing sneaky stuff, or do something like :

! -e $new && rename( $old, $new) || die $!
[download]

which is both longer to type, and has a race condition ($new could be created between the die and the rename).

Personally I would prefer rename to fail by default with an option to overwrite. It would make my code more robust.