OK, it turned out that the problem was not specific to Outlook Express, and
the inability by OE to open .eml files whose names were passed with the
"/eml:" command line switch was a red herring: OE _can_ open them, but they
must be passed complete with their (absolute) path, because apparently OE
changes the current directory to %HOMEPATH% (\Documents and
Settings\%USERNAME%) _before_ parsing the arguments (booo!), so a file
passed with a relative path is not found within the directory that was the
current one when the command was issued.

But as I said, the problem lied elsewhe namely, in the "Cache-control:
no-cache" HTTP header sent by my webserver. It appears that MSIE takes a
fundamentalist approach to compliance with it, and deletes the downloaded
file from the cache (%HOMEPATH%\Local Settings\Temporary Internet
Files\Content.IE5random_subdir ) immediately after completing the
download, without even giving the helper application associated with the
filename a fighting chance to grab it... Replacing the "no-cache" parameter
with something less harsh, such as "max-age=120", fixed the malfunction.

It still remains necessary to use a content-type "application/octet-stream"
in order to prevent MSIE from opening the document in its own window as
MHTML, but that's a minor annoyance.

Anyway, many thanks to all who kindly posted followups to this thread!

Enzo