It's just a personal choice of the linux designers not to allow it -- all the pseudo-security reasons, given, are specious, as there are unix systems that allow this.
I think this functionality came down to whether or not your unix's behavior followed 'System-V' (AT&T) or Berkeley's unix (BSD)...
As for other security issues mentioned:
Impersonating another user (or even root) via setuid.
Non-issue: Changing 'owner' clears any 'setXid' bits (U/G)
Having insufficient privileges to undo a mistaken chown
Not really a 'security risk', BUT, it might be on systems that
allow changing user, you can change it back if it is in a directory you own, other wise: 'be careful'!
Making it appear that someone else had created a given file.
It would still be in a directory that is writable by you.
I.e. you couldn't move it into their homedir, unless the have it open for write to your group or all (or you specifically if ACL's are available).
Setting up cron jobs to run on other user's accounts.
Again, wouldn't work -- since the crondirs are owned by user and not set to even be readable by other users, let alone writable.
if anyone could change the ownership, then anyone could change the permissions to gain access to any file on the system.
Nope: only if the user 'owns' the directory containing that file. I.e. I can give a file named 'passwd' to root, but I couldn't move it into /etc/ unless I have write permission to /etc/.
A potentially valid point -- IF you use quotas, but it seems like it would be easy to detect if you sum-up disk space by home-dir; The only problem would be in dirs that are writable by multiple users. In which case, maybe going by the owner of that 'dir'. It MAY be the case on those systems that support 'giving away' files, that you can only do this in directories that you 'own', but it's been a LONG time since I've actually been on a system that allows this, so I don't remember the exact restrictions.
I seem to remember there being some 'trade-off' for allowing 'giving away files'... e.g. - on systems that allowed that, something else wasn't allowed that linux does allow, but can't remember what that was off hand...
I'd say the above 'answer' should be unmarked as the answer, as it's NOT the real answer. IT's more a design decision -- I just don't know what the tradeoff(s) were.
There may be security issues not raised above that would be valid concerns, but the ones above aren't valid.
IMO, it should be a system-settable 'value' in "/proc", but generally speaking, I think most people don't care that much.
If there was a strong need for it, 'chown' could be security-enhanced and modified to allow it and then setup w/setuid 'root' to enable it to implement such a policy.