The way this works on Windows (I think) is that internally, "cut" means "copy file path to clipboard", and "paste" means "move file from old place to new place". Thus, if you want to cut and paste from "Downloads" to "Documents", then it doesn't matter how big the file is: you just change a couple of directory entries without ever changing the file. If you want to do this across file systems, it has to do a copy.

I regularly use cut/paste to move files in Windows and Linux, not sure why the size is relevant.

Ctrl-a to select all files for example, ctrl-x to cut, alt-tab or navigate to a different directory and ctrl-v to paste.

You don't have to load it in memory. The desired behavior can be accomplished with mv.

Most people don't seem to know this, but you basically can cut and paste in the Finder.

First copy the files you want, then move them instead of pasting (Command-Option-V). This gives you the same behavior without the confusion/danger of the files being lost in limbo between cutting and pasting, which I think is honestly better UX design.

Cmd-C and Cmd-Opt-V copy and move a file for me just fine in El Cap.

Right, but the Finder does have Copy and Paste. Cmd-C and Cmd-V have worked in the Finder since the very first Mac. It's even in the edit menu.

I suppose they expect you to click and drag to move a file, rather than the slightly unintuitive Cut and Paste on entire files. There's no real physical analogy for a cut.

All right. Refusing to implement a useful feature for anyone because it's deemed too confusing for novices isn't any better than removing a useful feature because etc., though.

(The recent addition of a special hotkey to paste-with-delete is not much of an improvement, since it still obfuscates the actual, expected behavior (of Ctrl-X) in favor of a different, more obscure, but notionally "friendlier" alternative.)