The second worst decision would be not auctioning off their 16 million IPv4 addresses, right now, probably at peak value of around $250 million.
The transition hasn't really been that bad, it's picking up pace precisely because there is increasingly valuable commercial logic in doing so (v4 addresses cost a fortune, as you noted!)
I've been surprised on a number of occasions recently to notice I've been communicating by v6 from public wifi, other peoples' homes, etc. Progress is slow but it is also sure.
In the UK, once BT flick the switch on their home offerings, there will be very few significant sources of v4 traffic left in the UK still awaiting transition
This, I think, is the unpopular but true reason the IPv6 transition has been slow. It ties together two changes, "get rid of IPv4" and "get rid of NAT", and making a business case for doing both of those simultaneously is very hard. Lots of people understand NAT. Lots of vendors understand NAT. Lots of managers understand NAT. ("NAT", of course, means "PAT with implicit firewall," but "NAT" is the term people use.) You can get the same security and privacy benefits and an equally good or even better design without NAT, but that's not what people are used to.
If IPv6 had been a straightforward extension of IPv4 to 128 bits instead of a bunch of cool and reasonable and backwards-incompatible ideas, the transition would probably be done already. The tradeoff, of course, is we'd still be on the same quality of architecture we have on IPv4.
Frankly I can't see any way (that has at least some degree of sanity), to make a backwards-compatible replacement for IPv4 with significantly more address space than IPv4.
Extend ARP to support IPv6 addresses instead of designing NDP. Use DHCPv6 like DHCPv4. Don't have SLAAC; encourage the use of existing techniques (static addressing or DHCP). Don't have RAs.
Don't have privacy addresses, because they're not needed, because NAT is expected. Don't have Teredo, because again, you're expected to get IPv6 addressing from some NAT technology.
Note that I'm not super advocating for extending the IPv4 space to IPv6, except via 6to4 if you want to. IPv6 continues to be its own space. But the advantage here is that you don't have compatibility problems from clients that support RDNSS and not DHCPv6 (looking at you, Android) or vice versa, because the way you do things in IPv6 is just like the way you do them in IPv4 and you can use the existing software stack with just a different typedef. You don't have problems with IPv6's infatuation with multicast and aging network architectures that only begrudgingly support it and fall back to broadcast quickly (cf. https://blog.bimajority.org/2014/09/05/the-network-nightmare... ); you're only using network features that IPv4 already requires your hardware to support. And so forth.
No implicit 64/64-bit split in addresses, where if you want to build an equivalent architecture to IPv4 NAT, you must have at least a /64 (there are plenty of service providers that give you a /128, and your only option becomes NAT66). With IPv4, if you get so much as a /31, you can usefully put two computers behind it. With IPv6, there's no way to implement, say, SLAAC with a /127; you have to use static addressing or DHCPv6. And you lose privacy addresses, which means you have less effective privacy than IPv4 NAT.
That's the sort of thing I mean by "backwards compatible."
Once we're on IPv6, by all means, convince everyone that you have better ways of doing everything. But if you tie the IPv6 transition to "NAT is bad and if you need it you suck", "multicast is great and if you don't support it you suck", etc., the only thing you'll succeed in doing is delaying the IPv6 transition.
No. The sin was committed when IPv4 was made and not initially designed to allow for variable / expanded address space. Adding an IP Option to IPv4 packets that could carry extra address bits was not an option -- IP options aren't preserved much at all on the Internet: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-...
Furthermore, even if most routers didn't drop IP options, adding address space via IP option in a packet that old devices would nevertheless parse would have been hell operationally.
IPv6 has its flaws and its weirdnesses (multicast, mobility, slaac, etc.) might not all look so good as they did in the 90s, but the one thing that was unambiguously done right was a clear separation of address spaces from IPv4.