In the general case, the security goal is to reduce the probability that the internal 128-bit counter block ever takes the same value
when instantiating the GCM cipher with a given key. That is catastrophic in combination with the CTR mode.
The best strategy to minimize such probability depends on how the IV is generated.
Case 1: IV is deterministic, 96 bits long
If the IV is deterministic, it means that the sender has access to a reliable mechanism (like a counter) to produce a sequence of unique values through all invocations done with the same key.
A 96 bit IV is directly copied into the counter block, so the uniqueness properties of the counter directly transfer to the counter block.
The IV (and the counter block) will only repeat after $2^{96}$ invocations, which is a huge number.
The NIST specification concedes you can actually fix 32 bits of the IV to context information, and just have a 64 bit counter.
Case 2: IV is deterministic, but longer than 96 bits
If the IV is deterministic but longer than 96 bits, the uniqueness properties of the counter do not transfer to the counter block.
Now you have to consider the consequences of the birthday paradox because the initial counter block will now be a digest of the IV. Specifically, you end up with 96 randomized bits in the counter block that may collide.
You are likely to hit a collision with 50% probability after $2^{48}$ invocations.
If order to reduce the probability below $2^{-32}$ (as required by NIST), you must stop much earlier, before $2^{32}$ invocations.
Case 3: IV is random
If the IV is created randomly at each invocation, the birthday paradox kicks in with 96 bit nonces too.
You will need to invoke the cipher with the same key no more than $2^{32}$ times in all cases.
Conclusion
The recommendation to use a 96-bit nonce is motivated by interoperability (i.e. it's easier if everybody uses one length only) and efficiency.
A 96 bit nonce is more secure than longer nonces only when combined with a counter (and - informally - only if you create a lot of ciphertexts under the same key). A longer nonce is not less secure in case nonces are generated randomly (which is by far the most common approach).
Bootnote
As a matter of fact, long random nonces are more secure than 96-bit random nonces, at least in case of short plaintext (i.e. consiting of $<<2^{32}$ blocks).
The reason is that in the former case the 32-bit CTR counter field is also randomized, whereas the field is fixed to $0^{31} || 1$ in the latter (see section 7.1 in NIST SP 800-38D).
With long random nonce, you may witness a clash in the initial counter block with the target probability $2^{-32}$ only after $2^{48}$ invocations,
which is a better bound than what you get with a 96-bit long random nonce.