The justification for such an action appears to be security-thru-obscurity, a practice that rarely works, especially in these times of deep-packet inspection. It's an ineffective measure in that the same data can be "discovered" via malformed or misaddressed email back to the source domain. Yes, it requires an additional step to "discover" the missing data, but the systems involved are configured to give it up in any case (i.e., delivery failure messages).
If you read the comment section of Terry Frazier's post, you'll see the usual RFC's-use-the-word-'should'-which-means-you-can-deviate-and-still-remain-compliant argument. In other words, the usual perversion of embrace-and-extend. Not that it matters that the rest of the world has to work around it (anyone else remember the method involved in MS's web accelerator?).
I still haven't found out if MS-generated message ID's are random or not, but the discovery of this bit of info wasn't exactly encouraging.
Keep in mind that, at one point, MS didn't comply with the "unique ID" guidance either. These are the sort of vaguaries that are valuable when you need to trace/discuss evidence as one side or the other, in a court case, will have an "expert" that claims that all message ID's are unique to the message in question.