If it worked like that in other Mac apps, I wouldn’t mind. Then you would just adjust to “this is how MacOS does cut-and-paste” and after an initial adjustment it would make complete sense.
But in every other Mac app, even in TextEdit, you would Cmd-X to cut a piece of text and Cmd-V to then paste it somewhere else. The same logic is used to e.g. move an image within a note or email, which is also a file.
So Finder is simply inconsistent with the rest of the OS, and after 4 years as a Mac user I have just given up and use either drag-and-drop or a terminal when I need to move stuff.
The finder probably chooses this paradigm because cut + paste is destructive. If you cut text and never paste it, the next time you copy out cut you lose that text forever. So if you used the same paradigm for files in the finder, you could accidentally and permanently delete a file because you cut it and then fat fingered copy instead of paste. If this happens with text from a file you can often just close the file and not save to get your text back, or hit undo because cut text is part of your undo history (usually). But storing whole files in some undo history seems like it could go wrong real quick since either you couldn’t actually delete the file from disk until the history expired or the finder was restarted, or an undo might take a significant amount of time because you moved between file systems. Or imagine if the destination file system crashed during transfer or unmounted after. Then you couldn’t undo at all.
