The amount of trust you are required to place in them does not make you vulnerable even in a worst case scenario
Only if you believe they operate as stated (that is, you trust them - and in that case you shouldn't care if they could eavesdrop or not, because they will not). I tried repeatedly to explain that if they control the algorithms running in your PC, the keys, the nonces, the sequence numbers etc. they can make all the secrets visible to them. You say: "they told me how they operate, and in that way they cannot cheat". But if they lied (or they are mistaken) about how they operate, you know nothing.
No peer-to-peer data including their key exchange goes through the server.
The communication is still over the Internet, is not it? Everybody can see the packets, cannot they? Can they insert extra packets with their own information? And then the question becomes critical: what happens if two messages arrive with the same sequence number? If one of them is dropped, which one? This is how, with clever, innocent looking programming, the man-in-the-middle attack becomes feasible. Therefore, the issue about handling messages with the same sequence number is critical. It is a security issue, but more importantly a question of trust: did they leave open this back door for a future attack?
Whether it [Random Number Generator] is Mersenne Twister or ISAAC is a an (important, but) irrelevant implementation detail.
Not at all! The random number generator can be seeded with a known piece of data, like the serial number of the SW and the time. If it is also known by the server, it will know the sequence of the "random" numbers a client generates. If nonces, keys are derived from these numbers, they are known by the server (or mediator or whatever you call them), so they can learn your secrets. You have to trust them not to implement this kind of pseudorandom number generators, but you cannot tell for sure if it is not open source SW.
...message replay protection. It is a basic functionality found in all bulk transfer security protocols
I did not say it cannot be done securely, but you cannot be sure if it *is* done securely in proprietary SW. Especially, if nonces are not random, if your keys are known by the server. Also, as I mentioned earlier, it is a nontrivial issue what happens at a replayed or modified-replayed message blocks. They can open a backdoor.
[key generation] is described in a spec.
As it is described their keys are generated from random nonces. By now you should understand that the problem is not how to assemble the keys from these nonces, but how these nonces were generated. If they were members of known sequences, the keys are also known by the server.
...releasing source code that is different from the one that is used
You catch them immediately with recompiling the source. In fact, this is the test most people do with open source security SW. In many cases binaries are not even provided.
Which standards are these exactly ?
For example FIPS 140-2, but I meant common sense "standards", like backdoors, side channels, error tolerance, attack detection and response but most importantly: open source or third party (like government agency) evaluation under NDA.
MS is the last company I would ever trust
Not the last for me, but not among the top 500 either.
...how DH is used in authenticated key exchanges
You can separate secret sharing and authenticating the result with public key signatures. My point is that you might not be able to do either of these in a non-trustworthy environment. As I explained above, the man-in-the-middle attack could be made possible with improper reaction to duplicate messages, and the server knowing the private signing keys can easily forge signatures.
...almost an exact replica
This is the most dangerous statement in information security. As we have seen, a seemingly trivial detail, how a pseudorandom number generator is seeded, makes all the difference between a secure system and an insecure one.
The problem is in end-user trust in their binary distribution
This is a correct summary.
To me trust is based entirely on the reputation
You decide whom you trust. For me reputation is a volatile thing, you have it today but might loose it by tomorrow, and then you are in trouble with all the secrets you trusted to the wrong people. Companies are governed by financial interest, and I trust large companies often (but not always) act accordingly. Financial interests do not change that fast, but it might be just wishful thinking. Sometimes you have no choice: you have to trust the OS vendor your company imposed on you.