In historical context (OpenSSH sshd prior to 7.4) a recommendation to not set Compression yes does make sense:
OpenSSH 4.2 from 2005 introduced Compression delayed and explains why they made that the default in their release notes. There they also explain when/why Compression yes might be required and what risks it exposes:
- Added a new compression method that delays the start of zlib
compression until the user has been authenticated successfully.
The new method ("Compression delayed") is on by default in the
server. This eliminates the risk of any zlib vulnerability
leading to a compromise of the server from unauthenticated users.
NB. Older OpenSSH (<3.5) versions have a bug that will cause them
to refuse to connect to any server that does not offer compression
when the client has compression requested. Since the new "delayed"
server mode isn't supported by these older clients, they will
refuse to connect to a new server unless compression is disabled
(on the client end) or the original compression method is enabled
on the server ("Compression yes" in sshd_config)
Based on those remarks you can easily see why a security scanner that detects Compression yes might generate a warning.
It is a potentially risky setting only needed for legacy (already legacy in 2005) clients.
But IMHO the recommendation should then be to set Compression delayed, which is also the OpenSSH default.
But OpenSSH server 7.4 releases in 2016 and:
sshd(8): Remove support for pre-authentication compression.
Doing compression early in the protocol probably seemed reasonable
in the 1990s, but today it's clearly a bad idea in terms of both
cryptography (cf. multiple compression oracle attacks in TLS) and
attack surface. Pre-auth compression support has been disabled by
default for >10 years. Support remains in the client.
AFAIK that release also made Compression yes behave the same as the (from then on legacy) directive Compression delayed.
So for OpenSSH sshd 7.4 and newer Compression yes should not trigger any warnings.
It is a really bad thing when a security scanner generates findings and makes specific recommendations without providing any supporting reason and/or won't associate them with a particular version.
When asked about the source and rationale on Github in 2016 for the Lynis recommendation to set Compression no it seemed a combination of
... Compression is desirable on modem lines and other slow connections, but will only slow down things on fast networks. ...
"generally: do not enable settings you do not need"
Reducing features automatically reduces the attack surface which is valid and hard to debate but which also holds true for almost any other setting and is not indicative of any specific risk in using Compression delayed|yes
Compression and encryption is dangerous
in the context of CRIME and BREACH and similar compression oracle related attacks exposing secrets and/or credentials.
The first two reasons aren't very convincing and the last one is no longer applicable, if it ever really was, since for years already when compression is requested, by default any current OpenSSH server will only support that after a user has successfully authenticated.
