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?
With concatenation the caller only has to ensure the nonce is unique. For example they can use a counter that increments for each message. Incrementing a counter for each message is convenient in many scenarios, including encrypted network transports like TLS.

If you use xor or add nonce and counter you get overlaps, so a counter as nonce would be fatally broken.
The security of GHash, the MAC part of GCM, decreases as the length of the message increases. This means that it's a good idea to limit the maximal size of messages the receiver is willing to accept.

  forces the scrambling pattern to repeat every 2^32 16-byte block"


The pattern doesn't repeat, you simply MUST not encrypt a message longer than that size.

A 64 GiB message is a very unusual for authenticated encryption, since the receiver can't use the data before they verified the MAC on all of it. Typically you split long data into multiple messages, each with their own MAC. That way the receiver can verify individual blocks and then work with the plaintext, safe in the knowledge that it wasn't manipulated.