> I know you can Opt+Cmd+V but thats not the point, which is extremely poor UI/UX.
Cutting files is generally bad UX, and Windows (which has the function) handles it rather awkwardly. To be honest many of these issues you point out are tenets of macOS since the very first release of 10.0 and in many cases earlier.
Because on Windows the functionality is semantically inconsistent.
When you cut text you are removing it from one place and pasting it into another. As soon as you choose the action the text disappears.
When you cut a file nothing happens to the file unless you paste it somewhere - and for good reason, it would be insanity for a file to disappear in a similar manner and when the majority of uses for this function are to simply move a file (something most modern filesystems can handle quite gracefully) it would also be insanity to copy the file from the filesystem into RAM and then back into the filesystem.
The macOS paradigm makes more literal sense - you copy the file and then you can choose to either paste it somewhere or move it to another location.
Text on buffers are disposable (e.g. cut/pasting text) but files are not, as losing one can even be a tragedy without backup so I don't see much logic in treating them the same, specially since the mental overhead becomes a burden to the user (oh I'm pasting a file so I must remember to use the special command to cut a file) instead of putting the burden on the machine, specially since reducing mental overhead is arguably the sole purpose of
the machine.
And the focus of that complain was that the edit menu does not clarify in any way that the "Cut" command there is only meant for text, it should be renamed "Cut text" or something that the user can easily understand to be intended only for text.
Cutting files is generally bad UX, and Windows (which has the function) handles it rather awkwardly. To be honest many of these issues you point out are tenets of macOS since the very first release of 10.0 and in many cases earlier.