I have explained this in a blog post http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/ but it is also explained below.
When a file is copied it has to create a brand new file and assign it a new set of permissions so it get's the permissions from the parent folder as you know.
When a file is moved to another volume what actually happens is that it is copied to the new volume and the old file is deleted. So the same process is repeated as above as it is a new file again and needs permissions set.
When the file is moved within the same volume nothing really happens (at the disk level). It just changes the logical path location of the file. The actual data and physical file on the disk hasn't been touched or changed. Ever noticed when you move a 5GB file to another folder on the same drive it is done almost instantly? This is why, because it actually hasn't moved but pointer to where the file logically exists has changed. As it was not modified in any way the permissions don't change also.
This is the reason for this behavour.
Edit: Somthing addition I forgot to mention... The MS article isn't entirely accurate. MS quote:
By default, an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained.
The above quote only applies to objects that have given EXPLICTLY defined sec permissions (turn inheritence off).
As mentioned in my comments it is all about keeping the ACL entries as efficient as possible. Consider the following example:
To keep the explanation simple let's say you have a folder set to allow users modify rights only. Below this there 1000s of files and none of them have explicit permisisons set. It isn't very efficient to create ACL's for each file as they are exactly the same perms so it sets ONE ACL entry for the folder. This next bit is very IMPORTANT to understand; the files themselves have NO ACL PERMS. So when you move any of these file in to a new folder in the same volume MS claims the perms move with it (as above quote). Ask yourself this....how? There were no perms on the file in the first place to move across. This is actually incorrect and I just tested it now to confirm it. Lets say the destination folder you are moving the file to has perms to allow the everyone group modify rights only. Well since the file has no ACL directly it inherits the ACL of the parent folder. this means the perms have changed from users modify (old folder) to everyone modify (new folder).
Notice the difference?? This time around moving a file to another folder in the same volume actually has changed the perms, something MS says it doesn't do. Have I just found a mistake in MS documentation since 2000 lol??
Now look at the same scenario when using explicit permissions. If you set explicit permissions on a file within this folder (inheritence turned off) which for example denies users read access it now creates A NEW ACL entry specficially for this file. Now when you move the file to a new location it has an ACL entry directly related to it. In this case moving a file to a new location in the same volume RETAINS its permissions (as MS claims)!