During IKE_SA_INIT you negotiate cryptographic algorithms which I assume (correct me if I am wrong) are very similar to a TLS cipher suite (symmetric crypto algorithm and a hash function). You also do a Diffie-Hellman exchange which I assume is not specified in the SAi1/SAr1 because you always do DH in IKEv2.
Yes, they are similar. But there are no fixed cipher suites in IKE (i.e. algorithms of different transform types may freely be combined in a proposal - with some exceptions, like not negotiating integrity algorithms when AEAD mode ciphers are proposed).
The DH group is also negotiated with SA payloads (transform type 4), even though the initiator already sends a KE payload with its public DH value for a specific group. So if the initiator proposes more than one DH group it has to assume which group the responder might select (the responder could, of course, use the KE payload as strong suggestion towards the group that should be selected, but it might prefer it's own configuration or not even support the proposed group). If the initiator's guess was wrong and the responder selects a different DH group it will respond with an INVALID_KE_PAYLOAD notify containing the selected group. The initiator then has to send another IKE_SA_INIT request with an appropriately updated KE payload (and possibly an updated SA payload).
What I dont get why you would want to negotiate cipher suites again. RFC 7293 tells me that
All messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the IKE_SA_INIT exchange.
so what's the point of the SA offers in the CREATE_CHILD_SA request?
That quote is referring to IKE traffic, which is encrypted after key material has been established with the DH exchange during IKE_SA_INIT. But to transport traffic via IPsec it's necessary to negotiate actual IPsec/Child SAs within the IKE SA. The algorithms used for IKE and Child SAs may be different, actually, every negotiated Child SA could theoretically use different algorithms (that may usually not be the case, but using different algorithms for IKE and Child SAs is definitely common, e.g. AES-GCM for IPsec and AES/SHA-2 for IKE). That's why algorithms are negotiated in CREATE_CHILD_SA exchanges.
The CREATE_CHILD_SA exchange is also used to rekey IKE and Child SAs, and while different algorithms could theoretically be negotiated then (basically a new SA is created to replace the existing one) RFC 7296, section 2.8 discourages this:
Note that, when rekeying, the new
Child SA SHOULD NOT have different Traffic Selectors and algorithms
than the old one.
Please also note that, unless RFC 6023 is implemented, a first Child SA is already created with the IKE_AUTH exchange. The algorithms used for this SA are negotiated with SA payloads during IKE_AUTH (SAi2/SAr2 in RFC 7296). However, because there is no separate DH exchange for it (the keys for this SA are always derived from the IKE key material), no DH groups will be negotiated, RFC 7296, section 1.2:
Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
Thus, the SA payloads in the IKE_AUTH exchange cannot contain
Transform Type 4 (Diffie-Hellman group) with any value other than
NONE. Implementations SHOULD omit the whole transform substructure
instead of sending value NONE.
If that Child SA is later rekeyed, a DH group may optionally be negotiated to establish new key material that's independent of the IKE key material. Because no DH transforms were contained in the initial SA payloads used for this Child SA, configuration errors regarding DH groups for this Child SA may only be detected when it is first rekeyed and fails.
