Given the other strange, arbitrary restrictions we've seen in the wild over the years — no "special" characters, no longer than 12 characters, ad nauseum — my bet is that someone has it in his head that restricting the usable character set even further will somehow improve security.
How, exactly, a rule like this improves security, I'm sure he cannot say, at least in a sensical way.
Most of the time, these weird rules seem to come about because of misunderstandings. The no "special" characters rule, for instance, dates from a time when most web CGI code was in Perl, and with a specially constructed series of characters in a web input field, it was easily possible to "shell out" to the operating system and even get access to data. So security people told developers: "do not allow special characters! Ever!" Instead of understanding why this rule existed, they blindly followed the order. Over time the rule got distorted, and now, which particular set of special characters is disallowed varies from site to site.
The restriction on length is obviously based on confusion: a minimum length for a password is a good idea, but imposing a short maximum length makes no sense whatsoever. (Apparently someone thinks that too many characters might cause a buffer overflow?)
So Microsoft Live has a limit of 16 characters, ASCII and some other restrictions. I emailed someone that used to work on that team in a decently high capacity. He said it was a restriction in the original system, designed sometimes in the 90s, and that the password validation code is in several different places in the entire system (different products like Hotmail and so on).
The char limit, well, they had to pick a limit (you wouldn't want passwords of 2^32 size), and back then security wasn't as big a focus so someone picked 16.
The reason for the original restriction is lost to history, as is apparently the handling of special chars. It may have been as simple as someone piping something to a shell script to setup an account, and not escaping things correctly. Who knows.
At any rate, Live has some extremely competent engineers, and this guy is brilliant. He said despite how bad it looks, every time they review security and prioritize things to work on, the password restrictions on Live never rank very high, compared to other attacks. People simply are not having their passwords brute forced enough for it to be a serious issue. Investing in things like e.g., detecting phishing attempts, has a much better ROI.
eli's comment is right: You shouldn't be too quick to judge the quality of developers when they need to maintain compatibility. At best, you might find out that a developer from a long time ago, operating under who knows what constraints (time, technical), failed to properly foresee the usage of his system.
How does Perl CGI code make it possible to "shell out" to the OS? I'm sure it can do so if the application isn't coded carefully, but how difficult is it to avoid doing the equivalent of passing user input to eval()?
It's not hard to avoid that, but in the nascent days of the web, few people were thinking that way. We were naive in our code. Sloppy, quickly written Perl was the norm.
How, exactly, a rule like this improves security, I'm sure he cannot say, at least in a sensical way.
Most of the time, these weird rules seem to come about because of misunderstandings. The no "special" characters rule, for instance, dates from a time when most web CGI code was in Perl, and with a specially constructed series of characters in a web input field, it was easily possible to "shell out" to the operating system and even get access to data. So security people told developers: "do not allow special characters! Ever!" Instead of understanding why this rule existed, they blindly followed the order. Over time the rule got distorted, and now, which particular set of special characters is disallowed varies from site to site.
The restriction on length is obviously based on confusion: a minimum length for a password is a good idea, but imposing a short maximum length makes no sense whatsoever. (Apparently someone thinks that too many characters might cause a buffer overflow?)
[edit: wording]