In some instruction sets, there exist distinct instructions to load a register from memory, store a register to memory, or transfer things among registers. While some assembly language forms use the verb "load" for everything (e.g. Zilog's Z80 mnemonics use
ld (1234h),a and
ld a,b) , and some use "T"ransfer (e.g. the 6502 with TXA for "transfer X to A"), some use "move" for regster-to-register operations to distinguish them from loads and stores. If one has an instruction format like the 68000 which uses the same general instruction form for register-to-register, register-to-memory, memory-to-register, and even memory-to-memory operations, the verb "move" is probably a better general-purpose verb than any of the alternatives.
I have no idea about minicomputer or mainframe instruction sets prior to the 8080, but the 8080 used "load" and "store" for most memory-access instructions and "mov" for register-to-register instructions, but most instructions which could operate on an arbitrary 8-bit register could also operate on "M", which was the memory location addressed by HL, so a "MOV" to or from "M" would actually behave as a load or store.
As for the distinction between "copy" and "move", I suspect that has a lot to do with the fact that code can neither create nor destroy registers; they just exist. In describing the behavior of the code sequence
mov bx,ax / mov ax,1234, does it make more sense to say the first instruction copies bx to ax, and the second instruction destroys the value in
ax and replaces it with the value 1234, or does it make more sense to view the first instruction as having moved the value from bx to ax (making the value in ax a "don't care"), and the second instruction loads ax (which had been don't-care) with 1234? Sometimes the source registers is still meaningful after a register-transfer instruction, but since there's nothing in the instruction set to indicate whether it will be, and in many common situations it isn't, "move" seems reasonable.