I think DJB is arguing that there should have been a transition period where people moved to IPv6, but still continued to use 32-bit addresses. This could have been handled by setting aside a special part of the IPv6 address space for addresses that mapped directly on to IPv4 equivalents.
Then, over time, operating system vendors, Linux distributions, and network equipment manufacturers could have moved to IPv6 "painlessly." IPv4 would have been phased out-- you literally would have been unable to buy IPv4 gear or download IPv4 software-- just like you can't buy IPX or Token Ring gear any more.
Then, when the big crunch came, as it is coming now, we could all look around at our modern IPv6-only gear and have a chuckle at the expense of those old Windows 95 users who still had IPv4 equipment. Finally we would flip the switch, allowing everyone to use all 128 bits of IPv6.
Instead of doing this, the IPv6 designers decided that they would create a completely separate network namespace. If you choose to support IPv6 on your network, the burden of it falls on you. It's measured in terms of time spent, equipment bought, and so on. You won't see any benefit to supporting IPv6, however, until a tipping point is reached where "enough" of the internet uses IPv6 (for some definition of "enough".) At that point, everyone will benefit, probably including the people who dragged their feet during the conversion. So the rational, profit-maximizing strategy is to ignore IPv6.
In fact, address scarcity often helps the incumbent telecoms companies. Having control of a scarce resource, like IPv4 address ranges, is usually considered a good thing.
The working group should not have made ignoring IPv6 an option. They should have pushed for it to become the only choice for newer systems. The only way to do this would have been to have a backwards compatibility mode.