Conventional archive decryption creates the names of the encrypted files, but OpenSSL expects the -out argument.

Does this have a design purpose?

Archiving != encryption.

But you can encrypt an archive, so if your experience starts there, wouldn't it be normal to expect encryption software to perform similarly to archiving in password-protected compression software?

If someone erroneously expects encryption to work like archiving, then yes, that may lead to many other wrong conclusions as well.

Encryption means taking a piece of data and running it through an algorithm to get ciphertext, which should look like random noise. There may or may not be an encryption key involved. The encryption may or may not be reversible. File names (or really files at all; it's just data) are not involved in the process.

One might as well ask "why does not my modem record file names?"! Modulation and demodulation has nothing to do with files, only data. File names may be encapsulated within the data, but that has NOTHING to do with the modulation or demodulation, just as it has nothing directly to do with encryption. SSL encryption is independent of application.

I don't really have these God arguments, but it's interesting to me when scientific people go there (iow, something isn't the way it is because it has to be).

I see compression as inherently ciphered, and the files themselves as containers for archives.

You can run a file through a filter and consider the result new data, but it's really just the same file you input, all jumbled up.

An automatic .ciphered extension to the same file shouldn't surprise or offend anyone. Same the other direction.

There are some important nuances here, too.

Compressed data is encoded, not obfuscated. There's a big difference. No attempt has been made to hide the original data, and indeed some of it is often still readable. If some or all of the data does become unreadable to the naked eye, that's just a side-effect of the compression, not a goal in itself.

Also, data compression != archiving. The fact that several archive formats (such as the ubiquitous .zip format) support both functions somewhat obfuscates this reality, but compression and archiving are still very much separate processes.

Example: The tar utility creates multi-file archives, and that's really all it does. Telling tar to compress an archive just means it also pipes the data through a compression utility of some sort, such as gzip, bzip or xz.

If you open a compressed tar archive using a program with a GUI, this immediately becomes apparent: Open the file archive.tgz in 7-Zip, and you'll see within it another file, archive.tar. And inside of that file you'll find the actual archived data.

An argument isn't the purpose. I have not and will never state that archiving is the same as encryption.

I imagine as OpenSSL was designed for a different function (data streams?), they didn't deem it necessary to do the archive trick of outputting a file name, the one used as the encryption input.

The practical meaning, for me, is that I have to give OpenSSL encrypted files a name that indicates to me the file(s) I encrypted, manually.

The examples usually do that, but following them makes it blatently obvious to an insightful user that they're looking at an excrypted archive, when if a file name were stored in the encryption, you could name it anything and what you get out is what you put in.