The handling of passwords in a Microsoft OS is complex because they use passwords for many usages. The OS (or its domain controller) will store a hashed version of the password, but there are also values which are symmetrically encrypted with keys derived from the password or from the hash thereof. The authentication protocols do not include provisions for exchanging salts when some hashing must occur client side. It is difficult to alter the password processing algorithms without impacting a lot of subsystems and potentially breaking the backward compatibility, which is the driving force of the Windows ecosystem.
It goes down to strategic priorities. Microsoft knows that altering password hashing and authentication protocols to include a salt will have some non-negligible costs which they would have to assume (by fixing all the components which are thus affected). On the other hand, not changing the password hashing is rather "free" for them, because a flaky hashing algorithm will not convince customers to switch to other non-Microsoft systems (the OS market is, in practice, a captive market); it takes a lot more to force potential customers to envision an OS switch which is very expensive. Also, password hashing can arguably be qualified as "defence in depth", a second layer which has any impact only once a breach already occurred; as such, it could be presented as being of secondary importance. Therefore, it is logical, if irritating, that Microsoft does not update its poor password processing practices.
Historically, Microsoft did only one update, when they switched from NTLM v1 to v2, and it was kind of necessary because the older LM hash was so weak that it was beginning to be embarrassing. My guess is that it involved a lot of internal hassle and they are not eager to do it again.