To put it from another perspective: If the situation was reversed would you be blaming IPv4 and saying IPv4 should have been designed differently or would you just be asking why this guy from Android doesn't want to add DHCPv4 when DHCPv6 is supported? In both situations it's not IPv4/IPv6 to blame for the inconvenience, it's the guy taking advantage of the transition between protocols to do something stupid at the same time. No amount of changing the definition of IP is going to make them like DHCP, they'll always push some SLAAC-like address assignment onto users. The only reason they didn't for IPv4 was they came in after it was already the way instead of before networks were deployed and they could force it.
It's often very difficult to use IPv6 in practice, but not because IPv6 made it that way.
Or they're deployed because it's difficult to use IPv6 without them, even if you want to. For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely.
Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.
> For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely.
On IPv4 I assume you're doing something which boils down to (from whatever network configuration tool you use):
ip addr add 192.168.1.100/24 dev eth0
ip route add default via 192.168.1.1 dev eth0
ip -6 addr add 2001:db8:abcd:0012::1/64 dev eth0
ip -6 route add default via 2001:db8:abcd:0012::1 dev eth0
ip neigh add 192.168.1.50 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent
ip -6 neigh add 2001:db8:abcd:0012::2 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent
> Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.
I have a strong aversion to AWS... but if there is anything more difficult about this for IPv6 than IPv4 then that's entirely on what AWS likes to do rather than what IPv6 requires. E.g. if they only give you a dynamic link local gateway it's because they just don't want you to use a public address as the static gateway, not because IPv6 said it had to be so by not supporting unicast gateways or something.
There's also nothing about IPv6 ND that would make it take longer to discover the gateway from a statically configured unicast address than IPv4 ARP would take, but AWS may be doing a lot of optional stuff beyond just being a dumb gateway in their IPv6 implementation - again, not because IPv6 itself said it should be so but because they want to do whatever they are doing.
(I'm doing this using direct netlink calls from my init; this is all about booting as fast as possible. The IPv6 address information is coming from instance metadata.)
They're almost always deployed though because people end up liking the ideas. They don't want to configure VRRP for gateway redundancy, they don't want a DHCP server for clients to be able to connect, they want to be able to use link-local addresses for certain application use cases, they want the random addresses for increased privacy, they want to dual stack for compatibility, etc. For the people that don't care they see people deploying all of this and think "oh damn, that's nuts", not realizing you can still just deploy it almost exactly the same as IPv4 with longer addresses if that's all you want.