Certificate Verify in SSLv3 I'm trying to figure out the SSLv3 protocol for educational purposes and having hard time understanding mutual certificate authentication.

When the client requested to provide a certificate it also has to send a CertificateVerify message:
CertVerify = Sigclient(pre_master_secret, Msg1, Msg2)

Why the public key of the client is not used like it used for the server?
Lets use the text from the protocol for reference:


  After verifying the server's certificate, the client encrypts a
     pre_master_secret with the server's public key.  By successfully
     decoding the pre_master_secret and producing a correct finished
     message, the server demonstrates that it knows the private key
     corresponding to the server certificate.
  
  When RSA is used for key exchange, clients are authenticated using
     the certificate verify message (see Section 5.6.8).  The client signs
     a value derived from the master_secret and all preceding handshake
     messages.  These handshake messages include the server certificate,
     which binds the signature to the server, and ServerHello.random,
     which binds the signature to the current handshake process.


And your question is:


  Why the public key of the client is not used like it used for the server?


The method of establishing the secret is kept identical for SSLv3 with client authentication. The client authentication is added to the protocol. This way the implementation of the key agreement can remain the same, with or without client authentication. There is no need for a second pre_master_secret or random either, one is sufficient to derive the session keys.

Now the server is authenticated by being able to decrypt the pre_master_secret send to it by the client. This shows it has the private key that belongs to the public key within the (verified) server certificate.

The client on the other hand does not perform any operations with the private key in this protocol. On the other hand, the private key must be used over session specific data; if this wasn't the case the private key operation would be vulnerable against replay attacks. So a signature over the session data is used instead. No additional random values or challenges are required.