In the same document the authors in section 2.1 specifies the plaintext size to be between $0$ and $2^{39}-256$ bits = $2^{36}-32$ bytes = $2^{32}-2$ blocks of 16 bytes.
That's the rationale behind the choice of the counter size. Given that requirement it will never overlap/wrap, which means you will never end up having repeating the "scrambling pattern" for the same message.
This constrains the maximum message size to $2^{36}-32 = 68.719.476.704 B$ approximately 64GB which didn't seem a problem to the authors.
Now, this choice of the counter constrains also the number of messages that can be protected under the same key at $2^{(128-32)=96}$ since the nonce is made by 96 bits.
If you look at section 3.1 of this paper by the GCM's original authors they gave the rationale above for their choices commenting that "any mode built upon a counter mode will have a similar tradeoff" {between maximum message size and number of messages under the same key}.
Now, you can easily modify GCM, by increasing the counter to 64 bits and decreasing the nonce to 64 bits and still have a secure authenticated encryption mode.
AES-CCM, for example, by specification support messages up to $2^{64}-1$ bytes.