For most users, the transition will happen via dual-stack (where the customer runs their own IPv4 NAT), not NAT64.
If so, that is a difference from IPv4. Don't block IPs, block subnets. Block the whole /64. It's what you were doing with IPv4 anyway - blocking a whole building / office / etc at once!
That's still no reason to turn IPv6 off in my humble opinion...
Most stuff defaults to bucketing by /64s.
IP blocking is far from ideal, in both versions of IP.. IPv6 makes this no better, or worse.
It's entirely reasonable to say "It works fine without [=zero business value], no need to invest that amount of work.". This makes IPv6 a negative value proposition for many orgs.
I mostly focus on users of VPN services. It's still rare for them to handle IPv6 traffic. So if you have IPv6 connectivity, IPv6 will leak, bypassing the VPN. Unless you have firewall rules, or disable IPv6 while using the VPN.
The funny thing is, there will be mandatory NAT on the carrier side during transition to IPv6 because of unwillingness of major websites to announce AAAA (including this one). See [0] for some transition method examples. The common theme of these methods is: They spoof DNS to point to fake IPv6 addresses, which is horrible, HORRIBLE, but hopefully motivates IPv4 holdouts to move to IPv6, announce AAAAs.
If you want to see what a wasteland IPv6 still currently is, and why such transition NAT madness will be necessary (sadly): Try disabling IPv4 when you have native IPv6 and your carrier has not enabled such DNS spoofing transition methods yet.
[0] https://en.wikipedia.org/wiki/IPv6_transition_mechanism