AES-GCM is not the same thing as AES. AES-GCM uses a 96-bit IV, or transforms a non-96-bit IV into a 96-bit IV before use. The particular constraints of the RBG and Deterministic constructions mean that not all of those 96 bits are expected to change between invocations. An IV collision (two uses of the same IV with a given key) is catastrophic to GCM's security, and therefore must be avoided.
The "Birthday bound" of an n-bit value is $2^\frac{n}{2}$, so a 96-bit IV has a bound of only $2^\frac{96}{2}=2^{48}$ blocks. But both recommended IV constructions keep some bits of the IV fixed, resulting in the lowered block count recommendation. EG
this Recommendation suggests, but does not require, that the leading (i.e., leftmost) 32 bits of the IV hold the fixed field; and that the trailing (i.e., rightmost) 64 bits hold the invocation field
means that only 64 bits of the IV would vary, so $2^\frac{64}{2}=2^{32}$ blocks can be safely encrypted with those GCM settings. Other IV generation methods similarly tend to reduce the number of varying bits. Fixing some bits allows for multiple sources to encrypt data using the same key. If one bit is fixed, two devices can share a key. If two bits are fixed, 4 devices can. Etc. If no bits are fixed, then each device must have its own send and receive key for each other device. Since this part of the spec is about fixed, shared keys the storage requirements would quickly overwhelm small systems.
