For GCM, the requirement about the IV/nonce is that it is unique per message. It does not need to be random; that's a good way to do it, but not the only way. There are other mods where the nonce does need to be random.
For CTR, the requirement about the nonce/IV/counter is that it is unique per block. Incrementing a counter from 0 is fine, but you have to increment it per block, not just per message. That is, the counter value needs to be unique, not just the initial counter value. The block size is determined by the underlying block cipher; it's 16 for AES (regardless of the key size). For example, if you send a 48-byte message then a 64-byte message with the same key, it's fine to start the first message with 0 (so it will consume the values 0–2), and the second message with 3 (so it will consume 3–6). It wouldn't be fine to start the second message with 1: that would leak information about blocks encrypted with the same counter value.
GCM uses CTR internally, but GCM takes a 96-bit nonce and uses that plus a 32-bit block counter as the CTR counter value. So with GCM you don't have to worry about the message length, you can use a simple incrementing nonce per message.
If you have a library that provides AES-GCM and incorporates the nonce generation (so you pass it the key and the message, and it produces cihertext that starts with the IV that it chose at random), then by all means use this. The only case in which this would be unsafe is if you don't trust the underlying random generator.
For example, if you're on an embedded platform with no RNG, but a pre-shared key and storage for a counter value, you could keep a running counter across all messages. But in this scenario you could also implement a PRNG and use that for the counter. A running counter is a bit easier to implement if you're doing everything from scratch. But if you're on a platform without stringent limitations and with readily available libraries, the simple option is to use a random initial counter value. This will require less custom plumbing between messages, and reduces the risk that you later change the padding mode to one that needs random IVs and forget to adapt the IV selection.
Note that counter values can be reused freely with different keys. It's only using the same counter value with the same key twice that's bad.