1. Just because we have 128 bits doesn't mean we have to use them all right now.
2. As anyone who's familiar with data compression knows, there are ways to represent some values in convenient forms and other values in less convenient forms.
3. There is a trade-off between ease of allocation and ease of use. Maybe we shift the focus toward ease of use if we want wide adoption.
With the benefit of hindsight, one way the IPv6 rollout could have been done differently is to have initially restricted ourselves to 40 bits of the address space. Thus we'd have started with addresses that look like (say) A.B.C.D.E instead of the current A.B.C.D.
Such a (hypothetical) system would be easy for an end user to handle, and most importantly that could be enough to get us over the hump to IPv6 adoption. Longer addresses would be valid, but they just wouldn't be assigned until later.
Of course, this is not quite how IPv6 works. But they do have a syntax that allows omitting zero values, and if addresses were assigned so that more of them were zero, it would make the UX better.
Also, thinking about it in this way, "end user" for IPv6 does not only translate to the developers working with IPv6 as consumers (think someone getting an IP from AWS for deploying their app), but, for maximum effectiveness, should also include the developers working on the implementation as well as distribution end of the technology. As always, these two (or more) groups have different levels of motivation to adopt and use the technology, and as such it is likely that the usual tradeoffs can be made (making something a bit harder to implement, for the sake of much increased "consumer" experience).
Ideally there would be a spec and an implementation that would appeal to both allocators as well as consumers of the address space.
it's a 128 bit number. no matter how you encode it, the ux is going to suck.