If you're writing code, you'll be either manually specifying the IP address family (so there's no real IPv6 risk) or you're probably using middleware that does all the hard parts for you anyway. If anything, I'm annoyed how hard it is to get a socket listening on both IPv4 and IPv6 in many low level libraries. I just want a socket to receive data on, who cares what address family it's from.

In my experience, IPv6 Just Works (tm) with modern software. There are some mid 00's frameworks for blacklisting abusive hosts that can't parse IPv6 addresses, or don't understand the /64 subnet you need to treat as a single IP address, but that's all I've ever run into. If anything, that gave me an excuse to finally get rid of an old Perl network filter running on my server.

I'm not sure how many tests the average piece of software needs that deals with the type of address family connecting. I suppose it matters if you want to test your rate limiting middleware or your logging library? That should only matter for the vendored code of course because modern libraries all have those tests themselves already. It's not like you need to run and write every test twice, only one or two very specific subcomponents if any.

If you're writing firewalls or kernels or router firmware then yeah you'll have your hands full with this stuff, but that's far from the standard developer experience. In those cases, IPv6 is a reality as much as TCP and UDP are.