This is an issue, but in typical dynamic IP situations the IP tends to only change when there's some sort of disruption that prevents renewal and not very frequently (e.g. I've held a Comcast consumer IP for over a year before), which tends to mitigate this effect since the IP changing "out from underneath" the tunnel won't occur. Most dynamic DNS schemes, with DNS caching added on top, also tend to result in pretty long (hour +) delays on IP updates to DNS which further make this a bit of a non-issue.
That said, I do believe both IPv6 and OpenVPN will have this exact same problem - IP change will not be reflected until something forces setup to repeat. The difference would be that these, at least I do believe, will re-resolve on retries. Wireguard doesn't really have a sense of "retrying the connection" which makes it sort of philosophically difficult for it to do so.
One very common scenario where WireGuard fails - you have a WG persistent VPN enabled and you actually move into the network that has the VPN endpoint. The IP of WG endpoint changes from a public one to a local one.
This keeps happening to me all the time, and it is no problem.
Once I move into the network that has the respective VPN endpoint, the subnets that are routable via wg become routable via ethernet/wifi which have higher priority, so the traffic will go directly.
That said, I do believe both IPv6 and OpenVPN will have this exact same problem - IP change will not be reflected until something forces setup to repeat. The difference would be that these, at least I do believe, will re-resolve on retries. Wireguard doesn't really have a sense of "retrying the connection" which makes it sort of philosophically difficult for it to do so.