While it did once have some performance implications, I think the real reason is for expressing your intent cleanly. The real question is whether something while (*d++=*s++); expresses intent clearly or not. IMO, it does, and I find the alternatives you offer less clear -- but that may (easily) be a result of having spent decades becoming accustomed to how things are done. Having learned C from K&R (because there were almost no other books on C at the time) probably helps too.
To an extent, it's true that terseness was valued to a much greater degree in older code. Personally, I think this was largely a good thing -- understanding a few lines of code is usually fairly trivial; what's difficult is understanding large chunks of code. Tests and studies have shown repeatedly, that fitting all the code on screen at once is a major factor in understanding the code. As screens expand, this seems to remain true, so keeping code (reasonably) terse remains valuable.
Of course it's possible to go overboard, but I don't think this is. Specifically, I think it's going overboard when understanding a single line of code becomes extremely difficult or time consuming -- specifically, when understanding fewer lines of code consumes more effort than understanding more lines. That's frequent in Lisp and APL, but doesn't seem (at least to me) to be the case here.
I'm less concerned about compiler warnings -- it's my experience that many compilers emit utterly ridiculous warnings on a fairly regular basis. While I certainly think people should understand their code (and any warnings it might produce), decent code that happens to trigger a warning in some compiler is not necessarily wrong. Admittedly, beginners don't always know what they can safely ignore, but we don't stay beginners forever, and don't need to code like we are either.
It is possible to create Windows executables on a Linux build machine by using a cross-compiler. But, Intel does not provide such cross compilers.
To answer the sub-questions:
What are the object file formats of gcc, g++, cl, mingw32, icc, icpc, and icl on Windows and Linux (current versions)?
The format for the object files is effectively determined by the operating system (or rather, the compiler used to build it). For Windows, this is the Portable Executable (PE) format and for Linux the ELF format.
Could parts of the mingw32 cross-compiler toolchain be used to accomplish the goal?
No. The relevant part is the code generator, which is both the part responsible for generating the right object format and the part on the Intel compilers that gives their generated code the speed edge.
Am I right that the metadata in the generated object files is the main issue?
No. It is one issue, but there are more. A more fundamental problem is the potential difference in how parameters are passed to the kernel and/or standard library. IIRC, those conventions are different between Windows and Linux.
Best Answer
It's not redundant in terms of language, it's just that by using it, you're telling the compiler, you would "prefer" to have a variable stored in register. There is however absolutely zero guarantee that this will actually happen during runtime.