Does the speed of operations on a file (copy, move, remove) depend on permissions of that file? If so, then how?
Speed is something that is wholly defined by the file system: For example, a move within the same file system will only be changing entries in the file system data structures and hence doesn't touch the actual file contents. Therefore, the time this takes will be dominated by the time it takes for your system to switch from your program to the kernel to do that, and the complexity of operations on these data structures.
That complexity should be the same, no matter the permissions. But: there's more to permissions than read/write/execute for owner,group,others; there's ACLs and xattrs, too, and that can get more complex in special cases. But these very likely don't matter to you at all.
The only case where permissions might matter is if concurrent access to the file needs to be coordinated (e.g. on a network file system mounted via NFS), but even then I've yet to see such a difference.
So, now, normally, things are "fast", full stop. The point that you're asking this, but do not even mention the actual file system you're using probably means you're worrying about the wrong things. It's very likely you can find differences between your file systems. For example, if you're often copying files, then using a file system that knows multiply-referenced extents will greatly speed up things. Currently, under Linux, there's only two choices there: XFS and btrfs. But even between these two, you'll find measurable speed differences when doing a lot of operations (say, upwards of 10000 per second). I tend towards XFS, but do your own benchmarking; with LVM it's really trivial to make and destroy file systems just for the heck of it.
The fact that you're using the tags rm, cp, and mv, however, might mean that you're equating the time it takes the shell tools of the same names to finish. And that's a very different problem: Calling
/usr/bin/rm¹ takes way, way, way longer than the actual deletion of that file. If you're seeing this bottleneck from a shell script, or from some language where you explicitly have to call these tools to modify the file system, it's quite possible that your process creation is your bottleneck - and not your file operations themselves.
¹ that is,
forking the starting process,
execve("/usr/bin/rm") in the fork, Linux loading the program into RAM, allocating memory for the process the dynamic linker trying to open about 20 libraries, then actually loading one, allocating way more memory, doing a lot of file properties,
opening stdout and
stderr... then closing all this again, before actually
unlinking the file... that's 100× the effort of the actual deletion request (that