AES can be used with 128, 192 or 256 bit keys and each one appears to have a performance vs security trade-off (What is the effect of the different AES key lengths?, What are the practical differences between 256-bit, 192-bit, and 128-bit AES encryption? and other answers). It appears that from a practical standpoint, 128 bit keys are sufficient for using AES encryption alone.
However, it seems like this equation changes when we use AES GCM/CCM. My understanding is that the same performance effects of using larger keys do apply for AES GCM and AES CCM, but the security strengths of brute forcing the key are different ($n \over 2$, https://www.rfc-editor.org/rfc/rfc3610) due to pre-computation attacks enabled by reuse of nonce/IV for different keys. There appear to be suggestions in the RFC where the nonce/IV for these modes include a salt(random) and a counter to provide a slight increase in security against pre-computation attacks.
Does this not reduce the number of blocks and max data size that can be encrypted under the same key? The amount of encrypted data reduces for a randomly constructed nonce with AESGCM; why would this reasoning not apply for CCM?
In summary my questions are:
What are the main reasons why 256 bit keys are recommended for AES GCM and CCM instead of 128 bits, and why is AES-128 bit sufficient for encryption otherwise?
Will there be significant gain in performance using 128 bit vs 256 bit keys with AES GCM / CCM or do non-AES part of AES GCM / CCM dominate performance or execution time?
Do the restrictions on message size and total amount of data authenticated under the same key change with TLS like nonce construction (32 bits random, rest of it a counter)?
Is ChaCha20-Poly1305 vulnerable to this pre-computation attacks?
ChaCha20-Poly1305 seems to provides 256 bit strength for encryption and a little more than 100 bits of security for authentication and the only condition seems to be related to the nonce just like the rest.