FWIW, that advice made more sense pre-internet, when compression formats were tighter and encryption was weaker -- the idea was that an attacker might find the key but not recognize that he successfully decrypted the data.
These days, even when we don't include cryptographic fingerprints (e.g., with the hash-and-encrypt construction C = E(M || H(M)) ) there's enough structure in compression format headers to allow an attacker to recognize if he has the right key... and he isn't going to be running a brute-force attack anyway.
Strong agree. One of the big philosophical problems in cryptographic engineering seems to be that much of it was designed to address data-at-rest, but most of the practical problems are about data-in-motion, and those are two different problems.
It's not so much that the data itself is in motion, but that online secrecy/authentication necessarily implies widely-available encryption/verification oracles. Oracles with possible implementation vulnerabilities (/features) that can be abused to answer questions such as "What's the encrypted encoding of the secret++X" or "How long does it take to check if X is valid" ?
Data in motion creates opportunities for adaptive chosen plaintext attacks that aren't present in data-at-rest scenarios. An "oracle" is a basic characteristic of a cryptosystem, not a flaw, but the "oracle attacks" you're thinking of are instances of adaptive attacks.
But it's not the fact that the data is being transported that's leading to new attacks, it's that the parties are online and responding to arbitrary messages sent by the attacker. The data itself isn't creating problems - what's new is the ability for the attacker to ask interactive questions of the parties.
When authenticating messages, a receiver necessarily gains the ability to reject a message as invalid. Adaptive chosen plaintext attacks arise when this rejection ends up containing more information than a simple Y/N. From the perspective of an attacker, the verifier becomes an oracle capable of answering say "How many bytes are valid", leading to a sub-brute-force attack.
These days, even when we don't include cryptographic fingerprints (e.g., with the hash-and-encrypt construction C = E(M || H(M)) ) there's enough structure in compression format headers to allow an attacker to recognize if he has the right key... and he isn't going to be running a brute-force attack anyway.