It could work without mode-config if the responder (“server”) was a device that allows you to configure all the aspects of the IPsec connection. Since it is a blackbox, you have to adjust the configuration of the Mikrotik acting as initiator to its expectations.
An IPsec “policy” is a combination of a “traffic selector” (matching rules for traffic to be chosen for delivery via the tunnel) and either a peer to deliver the matching traffic to/expect the matching traffic from and a phase 2 proposal used to establish a pair of SAs for that traffic with that peer, or an instruction to drop that traffic or leave it alone. So when I ask what the “traffic selector” is, I mean the src-address, dst-address, src-port, dst-port, and protocol items of the policy.
A policy may be configured manually or generated from a template. A manually configured policy that requires to deliver the matching traffic to a peer drops the matching traffic if the SA needed to deliver it is not available. A dynamically generated policy only gets generated once the IKE/IKEv2 SA with the peer has been established, so before and after that, the policy does not exist and IPsec ignores any traffic that would match it unless other policies match it too.
As I wrote above - normally, the responder would assign a single address to the responder and give it a list of subnets on the remote side to access (split-include in Mikrotik configuration); the responder would then dynamically create one policy per item on the list with the item on the list as dst-address and the assigned address as a src-address. In your case, it seems to work differently, so we need to know what the responder suggests as src-address to the Mikrotik using the mode-config mechanism, and adjust the policy template on Mikrotik side to limit that to what we need - IKEv2 allows to negotiate the actual traffic selector as an intersection of the ones proposed by both peers. So if the responder suggests I:0.0.0.0/0<->R:10.100.100/22 and the policy template at initiator side says I:192.168.88.0/24<->R:0.0.0.0/0, the resulting traffic selector will be I:192.168.88.0/24<->R:10.100.100.0/22.
As for IPv6, I don’t think it would help. The responder assigns an additional address or subnet/prefix to the initiator, and the initiator creates a policy to send traffic from that address/subnet via the responder by means of the IPsec SAs. If the address is an IPv4 one, you can use a src-nat rule to make a packet from any address match the traffic selector of that policy (policy matching takes place after srcnat). That’s what setting src-address-list and/or connection-mark in the initiator’s mode-config causes - for each such item and remote subnet, a src-nat rule is dynamically generated as soon as the IKE/IKEv2 session gets established. If the address is an IPv6 one, you either have to use a src-nat rule too, or it has to be a whole subnet and you must advertise that subnet to the LAN hosts and the LAN hosts must use an address from that subnet to talk via the responder, which normally boils down to having no other IPv6 address except the one from that subnet. And I even don’t know whether mode-config allows to assign a whole /64 to the initiator.
In what sense it “did not help”? It should not have helped to make it all work; it should have helped to maintain local access to the router even after the IPsec IKE/IKEv2 session got established, by preventing traffic within 192.168.88.0/24 (so between the configuration PC and the router itself) from getting hijacked by the dynamically created policy, and subsequently allowing to see what policy has been dynamically generated using mode-config, so that we could understand what the responder suggests and how to modify the template.