I guess I don't have as much low level experience as you do, but in my eyes IPv6 is literally just IPv4 with more bits. Due to the increased number of possible addresses, IPv6 is used with some different (better) concepts than IPv4. For example having (very likely) unique local networks (ULAs) is amazing when you happen to merge previously independent networks together or do some VPN stuff. You pretty much never have to calculate subnets because you'll likely never run out of addresses. And even if you somehow manage to do the impossible and fill up a /48 ULA (at which point you would have died from NATing billions of entire IPv4 address spaces with multiple layers to somehow make it all one network on IPv4), it takes just two seconds to generate a new one.
Also getting an entire public prefix assigned instead of just a single address is amazing too. On my public servers I let my ssh service listen on a randomly generated static IPv6 address from my prefix, which is not used for anything else. On that same machine I can have dozens of other public services on their own IP each (they can even all run on the same port because they're using different addresses), and when someone then decides to scan the IP of my website for interesting ports, they won't find anything.
To be honest, if someone doesn't understand IPv6, I doubt they really understand IPv4 either. Many issues with IPv6 today come from the fact that everyone and everything is so used to V4 concepts, that most products focus on IPv4 first and then half-ass IPv6 support (if they implement it at all).
The thing about IP and therefore with IPv6 is it's not just an address format - it's a set of protocols and practices so a lot of it changes.
Address asignment in an IPv6 world is more complicated - you can do DHCPv6, or your can do stateless auto-config. Which should you choose and when? Many other aspects of the stack require more knowledge.
And THEN you ALSO need to understand how v4 and v6 interacts so you can provide suitable compatibility - the various different methods of tunnelling and negotiation.
Using SLAAC is the way to go in most cases. DHCPv6 should only really be used when you have a network that is for some reason smaller than a /64.
In my opinion you shouldn't really bother with compatibility. Just do dual stack and maybe NAT IPv4 if necessary.
For my personal use cases IPv6 just proved to be much more versatile than IPv4. It did take some getting used to since it's approached differently, but learning it is very worth it and also helps using IPv4 better
Look at all the additional optional bits DCHP offers in terms of being able to communicate additional information to clients to configure themselves. Two big ones that stand out are timeservers and network booting parameters.
SLAAC is only a drop in replacement in the (typical) home.
That's just the addressing/subnetting though. Ipv6 and 4 for that matter also have a lot more going on in the packet handling and specification. and Ipv6's packet handling stuff is way more complicated than Ipv4. I was reading through just the ICMP parts and the difference is significant. I imagine the rest of it is the same.
Also getting an entire public prefix assigned instead of just a single address is amazing too. On my public servers I let my ssh service listen on a randomly generated static IPv6 address from my prefix, which is not used for anything else. On that same machine I can have dozens of other public services on their own IP each (they can even all run on the same port because they're using different addresses), and when someone then decides to scan the IP of my website for interesting ports, they won't find anything.
To be honest, if someone doesn't understand IPv6, I doubt they really understand IPv4 either. Many issues with IPv6 today come from the fact that everyone and everything is so used to V4 concepts, that most products focus on IPv4 first and then half-ass IPv6 support (if they implement it at all).