I originally posted this as a comment, but will flesh it out a little as an answer.
OpenSSH contains several utilities, among the most notable of which are
ssh will only connect to a remote computer (and possibly execute a command on that remote computer), other parts of OpenSSH such as
scp have a slightly different syntax. By virtue of all being part of the OpenSSH suite, these likely share a lot of code.
scp, you specify a remote file on a triplet form as
remotefilename may be a relative or absolute path.
If the host portion was allowed to be on the form
host:port, this would create a potential ambiguity: does
email@example.com:2222 refer to
~jdoe/2222 on host.example.com when connecting on the standard port, or does it refer to no file at all (or worse,
~jdoe) on host.example.com when connecting over port 2222?
The URI syntax that you present is more limited in what it can express (it doesn't allow for a filename specification), and even more importantly, there can never be ambiguity unless the actual host name includes a
: (which I don't think is even possible in DNS, and certainly isn't commonly done, whereas all-numeric file names aren't all that unusual).
When SSH was originally developed, it was developed as a more secure, drop-in replacement for the earlier RSH/rlogin suite of tools. I don't know what the command-line syntax for that was back in the early 1990s (the RFC describing rlogin is RFC 1282 from December 1991, predating the document you cite by about 15 years), but it doesn't seem an unreasonable guess that it used a very similar syntax because the user name was transmitted specially in the rlogin protocol. Quoting RFC 1282:
Upon connection establishment, the client sends four null-terminated strings to the server. The first is an empty string (i.e., it consists solely of a single zero byte), followed by three non-null strings: the client username, the server username, and the terminal type and speed. More explicitly: ...
The local username can be obtained through various system facilities, but the remote username must be specified explicitly somehow. Aside from
@ often being pronounced "at" and thus being a pretty natural choice to begin with,
user@host maps well to established syntax for e.g. email transmission (compare a SMTP address of
host may be an actual host or a DNS name with a MX record pointing to an actual host), so it was probably an easy choice rather than making up something new.
It's also worth noting what Stephane Chazelas pointed out in a comment: the document you refer to isn't an RFC, it's a currently seven years old draft which, judging by a quick Google search to confirm, seems to never have gotten off the ground. That happens all the time; something is proposed, but does not garner the support to actually make it into an RFC (and even many, many RFCs are non-standards).