Client authentication is for the benefit of the server. Preventing a man-in-the-middle is a distinct matter.
If the key exchange uses DH with a signature by the server (relatively to a public key which is known to the client) then the client is protected from a man-in-the-middle: the client has a strong notion of who it should be talking to, and the signature by the server prevents an attacker from impersonating the server in any way (e.g. as a "man-in-the-middle", which is just a specific kind of impersonation).
Without client authentication, the server does not know who is contacting it. The rest of the protocol (e.g. SSL/TLS) will still provide protection against attacks in the following sense: it will be the same client all along the session, and no other party may spy on the data contents or alter the data in an undetected way. As such, a "man-in-the-middle" (as in: an attacker who acts as a relay, decrypting and re-encrypting data on the fly) is averted, because the client has verified the signature from the server, and therefore used the "right" Diffie-Hellman key, keeping any attacker out of the key exchange.
Client authentication as a signature, computed by the client with his own private key and corresponding to a public key known to the server, could help preventing a man-in-the-middle in a devious situation where the client does not (stupidly) check the signature from the server. Nothing can prevent this moronic client from connecting to a fake server, since it checks nothing and can thus be embezzled at will. However, client authentication is enough for the server to make sure that if the client talks to it at all, then it will do so in a secure way.
The key point here is a matter of definition. What is a "man-in-the-middle" ? This is a case where an attacker impersonates the intended peer (for it to be a "true middle", the attacker impersonates the server with regards to the client and the client with regards to the server). This makes sense only insofar as there is an "intended peer". If the server does not care who is contacting it, then there is no notion of "man-in-the-middle".
In the usual HTTPS scenario, the client is authenticated through a password: the client needs to be sure to talk to the right server right at the beginning (using the server certificate) because the client does not wish to send his password to anybody. The server just wants to have continuity: if it got a correct password through a SSL tunnel then the tunnel is good and will keep on being so.