I thought it came from JCL's DD (Data Definition) statement. Even the parameter syntax is somewhat reminiscent of JCL's DD, while being completely alien to normal Unix commands.
The dd-style syntax isn't actually that bad. of=X if=Y is possibly easier to remember than -o X -i Y, while still being less typing that --output X --input Y.
JCL itself has a lot of warts, no denying that. But the basic idea behind the DD statement is interesting. In Unix, file descriptors are just numbers; whereas, in classic MVS, instead of numeric file descriptors the API uses 1-8 character names (DDNAMEs). While in principle a Unix program can inherit any number of file descriptors, in practice very few programs inherit any more than 0-2, because remembering numbers has poor usability. In classic MVS, it is not uncommon for a program to inherit more than 3 file descriptors, because they are assigned names not numbers. ("File descriptors" and "inherit" are not quite the right terms, but trying to use Unix-like language to make it comprehensible to people.)
(And I say classic MVS, because contemporary z/OS is actually a conforming Unix implementation so it supports numeric file descriptors in the Unix API, as well as alphanumeric DDNAMEs in the classic MVS API.)
My favorite, related, piece of trivia about JCL is the IEFBR14 program: the no-op program that took a few attempts to get it right :-) [1]. Its entire purpose was motivated by JCL not having primary commands to do file management, which is only allowed as a "side effect" of executing a program
I'm not sure it is fair to call that a wart. Back when JCL was designed, C/C++ didn't exist yet, and nobody used "//" as a comment syntax. (C's predecessor BCPL introduced // comments, but it was designed in 1967, and OS/360 was already shipping to customers in 1966; C itself was designed in 1972, and initially it didn't have // comments; C++ borrowed them from BCPL in the 1980s, and then C borrowed them back from C++ after that.)
A more obvious example of a wart would be how it exposes low-level details of disk layout (e.g. space allocation in cylinders and tracks), which improved performance and simplified implementation back in the 1960s, but which nowadays is just useless complexity–modern disks have completely different physical layout, and you have to buy expensive mainframe-specific SAN controllers which know how to simulate the ECKD physical layout of legacy mainframe disks on top of modern industry standard disks/SSDs.
I'm pretty sure that was coined specifically in reference to the Deskstar 75GXP series, not Deskstar drives in general. The Deskstar brand name is actually still used by HGST for its NAS drives, which seem to be reasonably well-regarded for their intended applications.
The reason is that scp was designed as a secure replacement for rcp, which was designed as a remote version of cp. The flags -p and -r were inherited from cp by rcp (see https://linux.die.net/man/1/rcp), so for compatibility scp had to use the same flags.
As for ssh, I haven't looked at its history, but I suspect it's older than scp; the intuitive flag for "port" is -p, so that's what ssh used.
I've been using a similar command called 'cheat' [pip install cheat] which does more or less the same thing. I wonder which of the two is more comprehensive. How would I check this efficiently?
