strongSwan

This behavior is on purpose, for several reasons:

The app strives for not letting any unencrypted packets leave the device until the connection is manually disconnected by the user. So we can't just disconnect if the server deletes the connection or is not reachable anymore, the user might not be aware of it. In this context "disconnect" especially means disabling the TUN device over which traffic is routed, the actual VPN connection (IKE/IPsec SA) may still be down temporarily.
If the app is used on mobile devices networks may be switched in quick succession, which is handled quite nicely by MOBIKE, often without the user even noticing. The VPN connection may be "down" when there is momentarily no network connection but will be "up" again quickly when the down time is short. MOBIKE will just update the tunnel endpoint address in this case. If the down time is longer and the server already removed the state, retransmissions may delay the VPN setup a bit (but because of that retransmission timeouts are configured rather short in the app - it takes less than 15 seconds before the app starts reestablishing the SA, compared to 165 seconds it takes using the default values).
There are currently some limitations to the MOBIKE/DPD/retransmission implementation (see also #455). For instance, if MOBIKE marks the SA as stale when there is no connection available, the current DPD code will still attempt to send packets. So if no network connection is available in time the SA will get closed and has to get reestablished - not really a problem as that could happen anyway, but it has some computational and temporal overhead we may avoid by not closing the SA preemptively. We could probably add a configuration option to prevent DPDs in such a situation, but it's one of the reasons for not enabling DPD at the moment.
DPD is currently also disabled to avoid constant network traffic, when there may be no need to (could safe battery power). If the server has DPD disabled (or uses a long enough dpddelay) the SA will be there quite a long time (until e.g. a rekeying is triggered on the server in a moment the client is not reachable), so there is no need to close the SA on the client if the server is only temporarily unreachable.
Another reason for not enabling DPD is that it's rather uncommon that the server is down or unreachable (for reasons other than the client having no network connection).

With that being said the GUI could probably be improved. For instance, we could show that the connection, while still active, might not be fully functional (e.g. go from "Connected" back to "Connecting...").__

I'm very interesting in this functionnality.