Re: No surprise, I predict that there will be more to come
IPv4 and IPv6 can co-exist. There was never any plan for an overnight switch from v4 to v6. IPv6 was designed to run in a dual stack environment where both v4 and v6 addresses were in use. If you were connecting to a system that also had a v4 and a v6 address, then local configuration will determine if you make the connection over v4 or v6, with the default to be to use v6.
Of course this isn't perfect. People can have a v6 iP that isn't able to connect to your v6 IP, and people don't want to wait 90 seconds for the v6 connection to time out before retrying on v4. This lead companies to develop a standard called "Happy Eyeballs" which try and learn whether to use v4 or v6. Yahoo! also sponsored an extension to BIND to try and help mitigate the split network scenario.
The real reasons nothing happened until it was too late was lethargy and inertia. Vendors didn't want to spend the (considerable) effort in making their products IPv6 compliant as it wasn't affecting purchasing decisions in the vast majority of cases. Customers weren't asking for V6 because either the people making the decisions didn't understand or because they didn't want to pay more to get v6. End user devices (DSL modelms, etc) didn't support v6 as ISPs didn't offer it, and ISPs didn't offer it because no devices could use it. A set of classic chicken and egg scenarios.
Yes, IPv6 was largely driven by academia, and that can be witnessed by the original specs for IPv6 autoconfiguration where the end client figured out what the subnet it was on was and then used its Ethernet MAC address as the last 48 bits of the submit and hey presto, you got a unique routable IPv6 IP. Its why IPv6 subnets tend to be /48s - the 48 bits in the MAC. It wasn't until years later that someone pointed out that MACs are globally unique (or are meant to be) so it didn't matter what network you were on, your computer could be uniquely identified through the IP it chose. A new autoconfiguration mechanism was released in the past 2-3 years to address that.
Even though Cisco has supported IPv6 natively in IOS for years, initial implementations were not carrier grade. IPv4 was handled through very efficient DCEF, which IPv6 packets were process switched, a very expensive process. Only recently has Cisco moved IPv6 into DCEF (or whatever they call it today).
As for CGN (Carrier Grade NAT, the industry term for what Plusnet is trying), there are a lot of implications and not all of them are well thought out. The issues raised in the article are relevant, and search engines and other such web sites are already concerned about the rise of CGN as it impacts their operations to not only monetise their search results and make them more relevant by using geolocation, it makes defending the sites against attack a lot more difficult as you can't just block the IP and affect a single user any more. The search engines have been in talks with ISPs for years about IPv4 to IPv6 transitions, and the need for CGN as an interim phase. Search engines would much rather we all move to v6, but thats not going to happen any time soon.
CGN also has implications for non HTTP traffic such as VOIP, as SIP really REALLY doesn't like NAT. That is one issue that I don't think is easily solved in CGN deployments without sniffing and rewriting the SIP control packets, which would be a non-trivial exercise with high traffic deployments.