Is there a strong cryptographic reason for GCM's 2^39 - 256 bit limit? In reading through the original GCM specification (McGrew &amp; Viega '05), the composition of the 128 bit Initialization Vector as a concatenation of a 96b nonce and a 32b unsigned wrapping counter seems arbitrary and forces the scrambling pattern to repeat every 232 16-byte block.

Is the algorithm expected to be secure for significantly longer stream lengths if for example the IV were a 128b nonce XORed with a 64b or 128b counter, or are there known cryptanalysis issues that begin to arise?
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.