what exactly this does?

is that like load balancing or like redundant options?

It's indeed redundancy. If configured this way, the initiator peer establishes Phase 1 towards two responder peers, but only establishes Phase 2 to one of them at a time. The responder peers both act as gateways towards the subnets accessible via the initiator, using VRRP or using some dynamic routing protocol to advertise themselves. There is no readily available interworking between the IPsec stack and the VRRP/dynamic routing, so the easiest way is that both the two responders have static routes to send the traffic for the initiator's subnets to each other and the IPsec policies are generated dynamically from templates on them. So on the responder currently chosen for Phase 2 by the initiator, the policies get created and "override" those static routes, whereas the other responder forwards the traffic for the initiator subnets to the "lucky" one thanks to those static routes if it receives it.

There is no automatic fallback - if both responders are available right after startup, the initiator sets up Phase 2 with the first one, but later on, if the currently used responder becomes unreachable/unresponsive, the initiator establishes the Phase 2 with the other one and keeps using it even if the first one becomes reachable again. If you don't like that, you have to use a script to enforce the fallback.