Почему команда ssh не следует за RFC на URI?

Я первоначально отправил это как комментарий, но буду конкретизировать его немного как ответ.

OpenSSH содержит несколько утилит, среди самых известных из которых ssh и scp. В то время как ssh только соединится с удаленным компьютером (и возможно выполнит команду на том удаленном компьютере), другие части OpenSSH такой как scp имейте немного отличающийся синтаксис. На основании всего являющегося частью комплекта OpenSSH, они, вероятно, совместно используют много кода.

С scp, Вы указываете удаленный файл на форме триплета как user@host:remotefilename, где remotefilename может быть относительный или полный путь.

Если части, относящейся к хосту позволили быть на форме host:port, это создало бы потенциальную неоднозначность: делает jdoe@host.example.com:2222 обратитесь к ~jdoe/2222 на host.example.com при соединении на стандартном порте, или делает он не относится ни к какому файлу вообще (или хуже, ~jdoe) на host.example.com при соединении по порту 2222?

Синтаксис URI, который Вы представляете, более ограничен в том, что он может выразить (он не допускает спецификацию имени файла), и что еще более важно, никогда не может быть неоднозначности, если фактическое имя хоста не включает a : (который я не думаю, даже возможно в DNS и конечно обычно не делается, тогда как все-числовые имена файлов не все это необычное).

Когда SSH был первоначально разработан, он был разработан как более безопасная, общедоступная замена для ранее комплект RSH/rlogin инструментов. Я не знаю то, что синтаксис командной строки для этого вернулся в начале 1990-х (RFC, описывающим rlogin, является RFC 1282 с декабря 1991, предшествуя документу, который Вы цитируете приблизительно на 15 лет), но это не кажется неблагоразумным предположением, что он использовал очень похожий синтаксис, потому что имя пользователя было передано особенно в rlogin протоколе. Заключение в кавычки RFC 1282:

После установления соединения клиент отправляет четыре завершенных пустым указателем строки на сервер. Первой является пустая строка (т.е. она состоит только из единственного нулевого байта), сопровождаемый тремя непустыми строками: клиентское имя пользователя, имя пользователя сервера, и терминальный тип и скорость. Более явно:...

Локальное имя пользователя может быть получено через различные системные средства, но удаленное имя пользователя должно быть указано явно так или иначе. Кроме @ часто будучи объявленным "в" и таким образом будучи довольно естественным выбором для начала, user@host карты хорошо к установленному синтаксису для, например, почтовой передаче (сравнивают адрес SMTP user@host, где host может быть фактический хост или имя DNS с записью MX, указывающей на фактический хост), таким образом, это был, вероятно, легкий выбор вместо того, чтобы составить что-то новое.

Также стоит отметить то, на что Stephane Chazelas указал в комментарии: документом, к которому Вы обращаетесь, не является RFC, это - в настоящее время семилетний проект, который, судя быстрым поиском Google для подтверждения, кажется, никогда не успешно стартовал. Это происходит все время; что-то предложено, но не собирает поддержку для фактического превращения его в RFC (и даже многие, много RFCs являются нестандартами).