There are some caveats to it

> The legacy SCP protocol (selected by the -O flag) requires execution of the remote user's shell to perform glob(3) pattern matching. This requires careful quoting of any characters that have special meaning to the remote shell, such as quote characters.

so I guess it is defending about theoretical problem where you use sftp-compatible quoting that silently breaks if you use same commands against scp script, still would be nice to have global config for scp fallback.

It's an intentional security thing. If the sftp subsystem command failed OpenSSH could fall back to scp automatically, but there are some security issues with that. Certain semantics, e.g. file name expansions, differ between scp and sftp on the backend, with the potential for some (theoretical?) exploits. IIRC, in particular, scp is invoked on the remote server through the shell, passing file names and commands as parameters, with shell expansion occurring. Whereas sftp file names and commands are issued in-band to the remote sftp subsystem using an additional protocol layer. (In theory the sftp protocol could be wrapped in TLS; it's independent of the SSH protocol itself.)

  The scp protocol is outdated, inflexible and not readily fixed. We
  recommend the use of more modern protocols like sftp and rsync for
  file transfer instead.

Yeah, regardless of how one feels about the design decision to fail without fallback, the messaging seems like an oversight.

Sometimes the message is different. I think it depends on the recipient server. Trying to scp to a dropbear ssh server on a router gives

   sh: /opt/libexec/sftp-server: not found
   scp: Connection closed

The -O resolution works.

Yes, please and thanks. And I want a single line explaining how it is failing so I can copy paste it into Google and make the trivial fix. I don't want the beginning of a novel. Java was famous for dumping not only the relevant error message but it's entire family history since birth.