This additional 32 bit nonce acts as a salt, and makes multicollision attacks $2^{32}$ times harder.
In this attack, the attacker collects a huge number of TLS sessions, each with a record encrypted with the same nonce. He then selects a random key, and generates the counter mode keystream for the key (and the fixed nonce); he then checks if that key stream allows him to decrypt any of the records (and he can do this considerably more efficently than individually checking each one, if we assume that he knows the plaintext for each one, or even if he knows a number of linear equations that holds for each one). If he finds such a random key that matches, he then has the key for that TLS session, and can decrypt it in its entirety.
If the attacker collects $2^n$ sessions encrypted with AES-128, he needs to check an expected $2^{128-n}$ random keys before being able to decrypt one; this is likely still infeasible for any plausible value of $n$, but still is easier than we'd like.
By setting 32 bits of each nonce randomly, this attack becomes more difficult. The attacker needs to select not only random AES keys, but also random 32 bits of the nonce settings, and he'll find a valid decryption only if all those bits are correct; this makes the attack require an expected $2^{160-x}$ random keys. Another way of looking at it; this multicollision attack doesn't make any sense unless an attacker collects at least $2^{32}$ seperate sessions; if he has less, it'd be more efficient for the attacker to select one session, and just brute force that (the 32 bit nonce doesn't make a brute force attack on a single session appreciably more difficult).
Also, it's not really important that the 32 bit nonce is secret; the same sort of logic would work if the nonce was public. However, there's no reason not to make it secret, and it was more convenient in the protocol.
