Why do client certificates not protect against improper server certificate validation?
The certificate-based client authentication in SSL takes the following format: the client shows its own certificate chains, and computes a signature over all the handshake messages previously exchanged. These handshake messages include the message where the server sends its certificate chain to the client.
In that way, the server can make sure that the client (the one who owns the shown client certificate) really saw the correct server certificate, not a fake one. In that sense, requiring certificate-based client authentication can prevent a true Man-in-the-Middle (if your “testing” shows otherwise then either you broke SSL, or there is something subtly wrong in your test situation). However, the Devil is in the details…
A MitM attack is a simultaneous double impersonation: the attacker runs both a fake server (when talking to the client) and a fake client (when talking to the server). A true MitM is prevented as long as either the client or the server correctly verifies the certificate from the peer, which entails validating the certificate (verifying that it has been issued by a trustworthy CA, and so on) and also using the name in the certificate as identity of the peer (a client connects to some IP address but the certificate is about a guarantee for a server name).
However, there are other kinds of attack which, while not being MitM in a strict sense, can be troublesome. For instance, if the client does not perform a correct validation of the server’s certificate, then the attacker can run a fake server and talk to the client. The genuine server is not involved at all ! That kind of thing is not a genuine MitM, but can be sufficient to recover some client secrets (the client believes that it connected to the correct server, and then sends sensitive data through the tunnel).
There is nothing that the server can do to ensure that a client always validates the server’s certificate properly — in particular when the server is not contacted at all, because the client is connecting to a fake, attacker-operated server. At best, the server can make sure, through certificate-based client authentication, that the client for this time uses the correct server public key for its cryptography.