Note I have read Why does the SSL/TLS handshake have a client and server random? and the answer makes it clear why the server random is necessary. However, since the premaster secret includes the client random, it seems like including the client random with the premaster secret when generating the master secret is superfluous.
For ciphersuites based on a key exchange and a signature as proof of possession, the sole way the server proves its identity is with the signature in the server key exchange message. This signature is tied to the TLS session because the signed data includes the client random and the server random. Apart from the client random, everything is chosen by the server, therefore the client random is the only thing that prevents anybody else from pretending to be the server after observing a single message from the server. A client trying to contact the legitimate server has no way to know that the server random isn't being repeated by an attacker. The client random is how the client challenges the putative server to prove that it is legitimate.
Even for ciphersuites where the client selects the pre-master secret and the server needs the private key to decrypt it, without a client random, two requests to the same server (with the same options) differ only because they have different server randoms. If I record a valid session then I can replay it to any client. I might not know what I'm sending, but I can at least feed obsolete information to clients that make identical requests.
The premaster secret does not contain the client random. It is a random key of its own. It is distinct from the client random because the client random is sent in the clear while the premaster secret is encrypted with the server public key.