Why can't AES-GCM be used in IKEv1 phase 1? I was configuring a VPN on a firewall (fortigate) and realized that I could use AES-GCM for encryption in the IKEv1 phase 2 but not in the phase 1 and I was wondering why knowing that in IKEv2 we could use it in both phases. I have already checked the RFC articles but there was no explanation. Is it only because AES-GCM came after IKEv1 or something like that?
With IKEv2 all payloads are generally sent in a single Encrypted Payload (SK) whose data is both encrypted and integrity protected/authentication (that protection covers the complete message, including the header and optional unencrypted payloads). That works quite nicely with modern AEAD algorithms like AES-GCM, the additional authenticated data (AAD) are the headers (IKE and SK) and any unencrypted payloads, the resulting authentication tag is what's sent as Integrity Checksum Data in the Encrypted payload.

On the other hand, IKEv1/ISAKMP handles encryption and integrity protection of IKE messages quite differently. For integrity protection of Phase 2 messages (Quick Mode/Informational), the message ID and the payloads are hashed (a PRF is used actually) and the result is added to the message in an additional Hash payload (during Main and Aggressive Mode it's similar but slightly differs based on the authentication method). The complete message, including that Hash payload, is then encrypted. So that does not really match with how AES-GCM works, unless the protocol would have been changed significantly (like getting rid of the redundant Hash payloads and handling integrity protection only via combined-mode cipher). But I guess there really was no point in doing that for an already obsolete protocol.

After writing this answer, I noticed that this is actually described in the introduction to RFC 5282.