I'm not aware of a conscious decision to change that setting, but there may have been one. I think MT might actually be the default though.
/MT - statically link runtime files.
/MD - dynamically link runtime files.
Here's why: If the Microsoft Visual C++ Runtime DLL is not installed on the target system, anything compiled with the /MD option will not run. This DLL is, I believe, installed with Visual Studio, and so /MD compiled programs will work on the developers machines, but often fail when deployed to client machines. Hence, the MT option is less likely to cause obscure and hard to debug problems. (How do you get good debugging information when the problem only occurs on the client's machine?)
The MD option should produce slightly smaller executables. But unless you're packaging your software with an installer that ensures the runtime library is installed, it might not run on the end user system. Also, considering the size of the DLL is about equal (or probably slightly greater) than who much would be stripped out of the exe, this doesn't exactly help packaging and distribution, unless you can ensure those DLLs are already present and don't need to be included in an installer.
Also, using MD requires runtime linking, which add slightly to the startup time.
Edit: One space saving for the MD options, is if you're distributing multiple EXEs in one package, all compiled with /MD, and an installer than ensures the DLL exists. Then you save space from each executable, at the cost of only a single extra DLL.
Mind you, as most packages are compressed, and the runtime code in each executable is the same, you might expect a solid archive to compress that code quite well anyway. I don't know if installers typically use solid archives, but it would make sense if they did. Solid archives compress all their files together in one big clump, rather than compressing each file individually. This allows for better compression, but to extract any given file, all files stored before it must be processed first. This makes individual file access slow, but is irrelevant if all files are being extracted anyway (such as what an installer would typically do).
MD does have slight disk space savings when lots of EXEs are installed and share a single runtime library, but with today's harddrive sizes, this is fairly irrelevant and I would be more concerned with the performance impact, and ease of distribution/installation.
