Rest assured, service providers are planning for v6. You're right that *having* to change will ultimately force the issue. Service and access providers face some hurdles that take time to work out.
1 - Carrier equipment isn't ready. Not all v6 support is created equal. The provider-side equipment must have support for hardware-accelerated packet forwarding. Many devices, like the CMTSs that cable companies use, make v6 support in software and max out their CPU long before reaching an acceptable throughput rate. Combine this with the fact that traditional channelized and circuit switched services (TV and Phone) are being transitioned to IP, and you see that replacement of major back end components will be required. $$$
2 - Customer premise equipment (CPE) isn't ready. Go find a SOHO router that has v6 support. Even when you find one, can you expect the next guy to pay the premium for the product? The home router vendors (i'm speculating) see supporting v6 as a move that would prevent them from selling another router in the future. Why sell one thing when you could sell two? They will wait until the last minute. Other standards, such as DOCSIS 3 and Packetcable 2.0, aren't fully implemented in traditional carrier-provided CPE.
3 - Providers are in the position of needing to replace CPE in every household to support IPv6. The same providers are looking at doing the same for the transition to IP Video, IP telephony, service mobility, etc. Given that each visit to the home costs $50-100, plus the cost of the equipment, it makes a lot of sense to get as many problems as possible solved with the fewest customer interactions and parts purchased. Imagine that the CPE costs $400 and the home visit costs $100. For just a million customers, it would cost $500M to do the change. Be glad the providers are doing this carefully, these numbers are too large to be absorbed quickly without changing your bill.
4 - NATing customers is an option, but it can break services. Ironially, the services it breaks are some of the ones the carriers provide. SIP-based telephony and video generally rely on UDP for signaling, as do the RTP carriers of media. Providers are getting pressure to support more consumer devices, and when they do, they have less control of the packet flows. Quality Assurance and interoperability testing becomes less and less viable. Proxies and NAT may be an option, but they are bad options. Carriers know this, and it means even more money to maintain service parity alongside meeting today's customer expectations of using the devices of their choice. It simply isn't all HTTP.
5 - There are some problems that we are only just seeing. When your provider applies a /64 address for its and your side of the connection, it must also provide address space behind your router. You get a /48, /56, or something like that. When this happens, changes must be applied on both sides of the connection to ensure routing works. The mechanics of the whole thing, and the options, best practices, and security policy on the customer side are not worked out, or are immature.
Acknowledging your assertion that we have collectively had enough time, I think we have much of the hard work done. Now some of the other players and business interests need to get their part done. It won't be too-little, too-late. It will be just-enough,at-the-11th-hour (once it gets painful).
Cheers,
rhadc