I suppose that you are talking about SSL. A SSL server supports several combinations of cryptographic algorithms called cipher suites. In particular, a given SSL server may support either or both of these key exchange mechanisms:
RSA: the server has a RSA private key; the client generates a random value (the "pre-master secret") and encrypts it with the server's RSA public key; the server decrypts the received value to get the pre-master secret.
DHE_RSA: the server has a RSA private key; the server generates a new random Diffie-Hellman key pair, signs the public part with its RSA private key, and sends that to the client; the client verifies the RSA signature (using the server's RSA public key) and completes the DH key exchange. (Variant: ECDHE_RSA: same principle, but the DH is done over an elliptic curve.)
So indeed, a given SSL server may potentially use the same RSA private key for both encryption (when using a RSA key exchange) and signatures (when doing a DHE_RSA key exchange). Note that the server may perfectly well have two RSA keys, one dedicated to encryption (RSA key exchange) and one for signatures (DHE_RSA key exchange); people just do not do that on a regular basis because having two distinct keys implies buying two distinct certificates.
In all generality, the same key should not be used for both encryption and signatures. Note that a big source of confusion is that RSA encryption and RSA signatures are two distinct algorithms, that just happen to use private keys that have the same format, and people found it smart to call both of them "RSA".
The two main reasons for not using the same private key for both encryption and signatures are the following:
Interactions between the encryption and the signature algorithm are not well-studied. There could exist some method that leverages encryption to forge signatures, or signatures to perform an underhanded decryption. In the specific case of a SSL server, it is usually believed that there is no such interaction, notably because when the server decrypts, it does not advertise the result back to the client, and also because when the server signs, it does so over a DH public key that the server generated itself, not over data sent by the client.
Normally, encryption keys and signature keys call for distinct life cycles; encryption keys should be escrowed, and signature keys must not be escrowed (see this for some discussion on the subject). Again, in the specific case of a SSL server, you do not need to escrow the RSA private key because the encryption is transient (data is decrypted when it arrives, not stored), so it is possible to manage the server's private key in a way which is fine both for an encryption key and a signature key.