I am not saying the current situation is a success. I am saying that DJB's plan would fail in the same way as the current situation.
I actually believe that with DJB's plan the situation would be *worse*. The more I look at it, the more I see in it an analogue of Greenspun's Tenth Law: it would have been an ad hoc, informally-specified, bug-ridden, slow implementation of half of IPv6. I try to imagine how its deployment would happen, and for every problem I see, the solution would be very similar to how IPv6 solved its own similar problem.
And in the end you have something with variable-sized addresses (even if it is just two sizes, it is still variable-sized), a very large number of deaggregated routes (I would expect it to cause the size of the routing tables in the default-free zone to double), and lacking several of the enhancements introduced in IPv6.
In DJB's plan, you have two classes of addresses: "new" (extended) and "old" addresses. In the same way, you have two classes of packets: "new" (with extended addresses) and "old" (normal IPv4). If a "new" address wants to communicate to an "old" address, or an "old" address wants to communicate with a "new" address, they have to use "new" packets. But to use "new" packets, EVERY SINGLE ROUTER in the path between them has to be able to understand "new" packets, else it will be dropped. How do you solve it?
A simple way is to compute a separate route which has only routers which understand "new" packets (this has to be done also for "old" destinations, because the source address could have to be "new" and thus also need the "new" packet). Now you have a situation similar to IPv6/IPv4 dual-stack.
Another option would be to tunnel automatically. Suppose you have a "new" host sending to a host with an "old" address. It has no way of knowing the host with the "old" address can understand "new" packets, so you need some crazy sort of NAT (here we see one point where DJB's solution is inferior - with the current situation, you know by the type of address whether the target host can understand it or not). But suppose that the target host understands "new" packets (or that you do not care if it does not). You send the packet, with a "new" source address, to the host with the "old" target address. Suppose some router in the path does not understand "new" packets, but your tunneling solution can work around that (by encapsulating the packet within an "old" packet, or by the construction of the packet itself). Where will the recipient send the reply to? It has to be tunneled; what will be the "old" address in the "old" outer packet? One simple solution is to embed this target within the "new" address, and now you have something similar to 6to4.
With all this, what is the incentive for ISPs, and equipment manufacturers, and in fact everyone else to upgrade to something which understands the "new" packets, "new" address format, and so on? After all, "old" addresses keep working, so why not just get a set of "old" addresses? And if everyone has a set of "old" addresses, why waste money upgrading the core? This is the same situation we have right now with IPv6.
Normal equipment upgrades will not be enough; with IPv6, we still have (as others have commented) new equipment with no IPv6 support, and IPv6 is simpler to implement. It is a separate protocol, so the code can be added separately, instead of having to change everything which touches IPv4 - which for a router is a lot of things. In fact, this is what Microsoft did with Windows XP (you have an IPv6 addon).
And 8 years is not nearly enough. Just for the end hosts (which tend to be easier), how long it took between IPv6 being designed and Windows Vista being released? As mentioned above, XP would not have it, since it could not be an addon. Worse, since it touches everything, it is possible that not even Vista would have it. Not even mentioning the backwards compatibility nightmare with legacy applications.
This all is just barely scratching the surface. It would be a fascinating experiment to actually write down the specifications for a "IPv4+" protocol, imagining how it would work in every situation. Perhaps we could even learn some things from it. It could even help with the design of future networking protocols, either as an example of what to do or as an example of what not to do. But it would not help with the current situation.