Apple - Why is it still not possible to cut files to paste them elsewhere in Catalina?

Because the Pasteboard, to which all data is Cut, is inherently transient and unsafe. If you could Cut a document in the Finder, that document would only reside in the Pasteboard, and any new Copy/Cut action would cause it to be lost.

You could never Cut a file in Pre-OS X Mac operating systems.

However, you can achieve the same result by Copying (CMD+C), and then Moving (Option+CMD+V).

Insofar as files are concerned, "cut and paste" is "move" by a different name. With Finder, as you have likely noticed, there is a rule behind its behavior during drag-and-drop operations on files:

drag-and-drop to the same volume: move is default.
drag-and-drop to a different volume: copy is default.

But if these default behaviors are not what you want, here's how to modify that:

Command key while dragging changes copy to move.

Option key while dragging changes move to copy.

If you find it tedious to remember this, one option is to use mv or cp from the CLI.

The clipboard metaphor doesn't really work well for files, and while "copy file" can be implemented transparently as "copy and paste", "move file" requires some judgements.

At its simplest, "copy" means putting some data into shared memory, and "paste" reading it back out; "cut" is then "copy" plus immediately deleting the source data.

For working with files, this would be incredibly inefficient - imagine if you selected a 2GB file and pressed "copy", and had to wait for 2GB of data to be loaded into RAM.

So instead, file management programs overload the "copy" command in some way so that what is put in shared memory is just a pointer to the file. They then overload "paste" to run an appropriate "copy file" command. The UI will act as though you've "copied a file to the clipboard", and "pasted it from the clipboard to a new location", but the file content itself is never in the clipboard.

With a straight-forward "copy and paste", this is mostly transparent to the user - the effect is largely the same as if the content was actually placed in memory. It also achieves what the user wants to do: copy the file on the filesystem, with the clipboard just being a UI convenience to do so.

The natural parallel is for "cut and paste" to mean "move file", but there's a problem. Normally, "cut" means "copy and then delete the original", but if the data hasn't actually been copied anywhere, the source can't be deleted yet. The actual "move file" command has to be executed when the user selects the target directory.

However you implement it, some of the expectations of the clipboard metaphor will be broken by any useful "move file" function.

You could special case "cut" to only delete the source content once it's been pasted. "Cut" can place a file pointer in the clipboard with an instruction that when pasted, the "move file" command should be used instead of "copy file". This makes "cut and then paste" work as expected, but if you look at the original file, it's still there until you paste it, which wouldn't be true if you "cut" any other type of data. This is how Windows Explorer works, for instance, and it tries to indicate the "cut but not deleted yet" state by rendering the file's icon transparent while it's "in the clipboard".

As a variation, "cut" could move the file to a temporary location, so that it is immediately removed from its original location. On many file systems this can be done with practically zero cost as long as the temporary location is on the same partition, by editing two directory entries. Then on paste, move the file from the temporary location to the target. This would make the file disappear immediately when "cut", but the user may still notice that "paste" is doing the actual move - for instance, a large file which has been "cut" will still take up space on its original partition. (I don't know if any OS / file manager uses this approach.)

Alternatively, you can offer the user a special "paste" operation which deletes the original. This makes it clearer that the source file has not been removed yet, but means that the "copy" command might result in deleting the source file, which would not be true of any other data. This is what MacOS Finder makes available: after copying a file, the user can choose to move it by pressing Option+Command+V instead of Command+V.

Although these approaches all need some of the same implementation, it would be confusing to offer more than one variation. For instance, if MacOS allowed you to "cut" a file, would Command+V do the same thing as Option+Command+V? Or would one of them be unavailable?