Got answer for Apple (for iOS not macOS ticket, Q.E.D. :)).
For IKEv2 on the iOS device to use the configured DH groups in Child Rekey, you will need to set the Enable Perfect Forward Secrecy option in the Apple Configurator application.
Had not checked that, facepalm.
For test have set Group 1 for 20 min rekeying, Group 2 for 10 min rekeying.
On connect phase 1:
charon 05[CFG] <31> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384
charon 05[CFG] <31> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384
charon 05[CFG] <31> received proposals: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384
On connect phase 2:
charon 11[CFG] <con1|37> selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
charon 11[CFG] <con1|37> configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/ECP_384/NO_EXT_SEQ
charon 11[CFG] <con1|37> received proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ</con1|37></con1|37></con1|37>
On rekey phase 2:
charon 10[CFG] <con1|32> selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/ECP_384/NO_EXT_SEQ
charon 10[CFG] <con1|32> configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/ECP_384/NO_EXT_SEQ
charon 10[CFG] <con1|32> received proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/ECP_384/NO_EXT_SEQ
charon 10[CFG] <con1|32> proposal matches
charon 10[CFG] <con1|32> selecting proposal:
charon 10[ENC] <con1|32> parsed CREATE_CHILD_SA request 2 [ N(REKEY_SA) SA No KE TSi TSr ]</con1|32></con1|32></con1|32></con1|32></con1|32></con1|32>
On rekey phase 1:
charon 15[CFG] <con1|31> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384
charon 15[CFG] <con1|31> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384
charon 15[CFG] <con1|31> received proposals: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384
charon 15[CFG] <con1|31> proposal matches
charon 15[CFG] <con1|31> selecting proposal:
charon 15[IKE] <con1|31> IKE_SA con1[32] state change: CREATED => CONNECTING
charon 15[IKE] <con1|31> 192.168.10.146 is initiating an IKE_SA</con1|31></con1|31></con1|31></con1|31></con1|31></con1|31></con1|31>
Seems to be rekeying now. ```
./iperf3 -c IPADDR -P 4 -f m -d -t 22 -O 2 -i 1
However
charon 10[CFG] <con1|37>lease 172.23.152.1 by 'ikemaster' went offline
charon 10[IKE] <con1|37>IKE_SA con1[37] state change: DELETING => DESTROYING
charon 10[IKE] <con1|37>IKE_SA deleted
charon 10[ENC] <con1|37>parsed INFORMATIONAL response 2 [ ]
charon 10[NET] <con1|37>received packet: from 192.168.10.146[4500] to 192.168.10.100[4500] (88 bytes)
charon 10[NET] <con1|37>sending packet: from 192.168.10.100[4500] to 192.168.10.146[4500] (88 bytes)
charon 10[ENC] <con1|37>generating INFORMATIONAL request 2 [ D ]
charon 10[IKE] <con1|37>sending DELETE for IKE_SA con1[37]
charon 10[IKE] <con1|37>IKE_SA con1[37] state change: ESTABLISHED => DELETING
charon 10[IKE] <con1|37>deleting IKE_SA con1[37] between 192.168.10.100[XXXX]…192.168.10.146[ikemaster]
charon 10[IKE] <con1|37>activating IKE_DELETE task
charon 10[IKE] <con1|37>activating new tasks
charon 10[IKE] <con1|37>queueing IKE_DELETE task</con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37></con1|37>
it seems that pfSense itself queues and executes IKE_DELETE and it happens both on macOS and MSW.