In my experience not true in practice cause I have experienced way more issues with the IPv6 endpoints of sites than their IPv4 counterparts.

This becomes noticeable when pipelines on IPv6 connected servers suddenly have random request/post failures to public services. Then either the whole service is temporarily having issues or there are a few bad IPv6 endpoints while all the IPv4 endpoints are fine.

Seemingly this failure mode can go unnoticed for days while the same won't be true for IPv4 due IPv4-only still being the norm for corporate networks. And no, current form of happy eyeballs v2 won't account for this.

Besides bad endpoints it could also be a problem with bgp route advertisements where the IPv6 prefix takes a weird path and ends up being blocked by a CDN at the other side of the ocean. This happens more than you'd think. Obtaining pypi packages was quite a challenge last year for us for a couple of weeks due to this.

Not really a fault of IPv6 technology wise, and in general can be solved client side through retry functionality, but in practice it still can lead to a worse outcome due to lackluster IPv6 adoption.

I used to think ISPs, organisations, admins and users were just being lazy for not implementing IPv6 or turning it off as the first thing to do when network problems happen, but when this far in the rollout such basic things still lead to difficult troubleshooting sessions then perhaps time has come to say something has gone terribly wrong.

It saddens me to say that I totally understand that businesses do not want to pay the price for implementing IPv6 unless absolutely necessary, because until the majority of traffic is IPv6 or even IPv6-only it does not make a lot of sense.

The flipping point is nearer than ever, though I fear it will in the short term lead to even worse stability for both protocols until IPv6 truly becomes the norm, whenever that may be.