Well not having to dualstack is still just nice. No more DHCP4, and so on – e.g. you can have SLAAC as the one and only very simple way of auto-assigning addresses (in a client setting, obviously not what you'll use with servers that have their addresses listed in DNS :D)

It would be nice if NAT64 was embraced everywhere, I love typing IP addresses because I'm lazy, but we need IPv6 right now.

There are still too many rough edges going V6 only though, like if I set my own DNS servers, will they resolve A records to NAT64 AAAA records? And how will the regular Windows sysadmin deal with registering DNS records?

We continue to suffer for the boneheaded failure to make NAT64 a mandatory, required element of every IPv6 router.

DJB saw all this with crystal clarity almost twenty years ago:

http://cr.yp.to/djbdns/ipv6mess.html

Note that when he wrote this, NAT64 didn't even exist. NAT64 is basically standardization of "make IPv6 work the way DJB said it should".

DJB's (sketch of a) solution seems more like 6to4, where every IPv4 address automatically gets a /48 IPv6 prefix. It was deprecated due to unpredictable reliability.

It doesn't make sense to have NAT64 on every router, because NAT64 is stateful and needs to be properly engineered into a network. There are also alternatives like DS-Lite and MAP, with different design tradeoffs.

Everyone who wants to is already doing v4 NAT along with IPv6 in a dual-stack setup. In this NAT64 alternate reality the discussed AWS configuration would be "v6-only vpc with NAT64 disabled".

(And mandating NAT in routers would be a pretty radical departure from the current internet architecture).

Far less radical than having two different versions of IP on the Internet at the same time.

When there was only IPv4 there was no reason for backwards compatibility. Caring about backwards compatability doesn't become radical simply because it becomes necessary.