Why restrict nonce/IV and counter to specific sizes? When setting up a nonce/IV and counter (e.g. for AES-GCM-128), why are the nonce/IV and counter restricted to specific sections (e.g. random nonce/IV in first 8 bytes and counter in last 8 bytes)? This results in the last 8 bytes always starting off at a predictable value (0), reduces uniqueness (only 8 bytes of random data), and requires more frequent re-keying due to counter wrapping.

Is there a reason the entire 16 bytes cannot be initialized to random data, start the counter from there, and allow the counter to use the entire 16 bytes?
The answer is that you can do exactly what you say. Initialize the counter to a random 16 byte number and start counting. Wikipedia (not sure if that is where you got the idea that it must be 8 bytes and 8 bytes) has the following note:


  The IV/nonce and the counter can be combined together using any lossless operation (concatenation, addition, or XOR) to produce the actual unique counter block for encryption.


There is some benefit to separating things though. For example, splitting it into 8 bytes and 8 bytes, as long as you never generate the same 8 byte nonce/IV while using the same key, your encryption stream will never repeat. Further, you know exactly how many nonces/IVs you can generate before expecting to see a repeat ($2^{32}$ from the birthday paradox) with about a 0.5 probability. In a submission to NIST by some very reputable cryptographers, this method of doing CTR mode was called "the recommended usage scenario". 

Lets instead assume you generate a 16 byte nonce/IV and just start incrementing it. What happens if two nonces/IVs have a difference of 1000 (i.e., $|n_1 - n_2| = 1000$). Well, after encrypting 1000 blocks (with the same key) you will now be using the same encryption stream. Analyzing this is a bit more tricky as you need to know the probability of generating two nonces that are within some range of each other (the range being determined by how many blocks you will encrypt). Depending on the application this could be a major problem. My guess though is that in the majority of applications it isn't a problem.