My take is that they should have used alphanumeric addressing. You could have addresses like company:office:laptop and it shouldn't have reinvented arp and dhcp or added more complex routing like anycast or link local. It tried to solve too many problems at once.
No, ipv6. Could have eliminated the need for DNS in a LAN. There is no reason to use hex other than maybe it would be easier for control planes to translate config to bytes/asic? But that's only when a config changes. Routing and forwarding uses bits and bytes, the hex is just one of many ways they could have chosen to represent the bytes. Defining prefixes in alphanumeric and how that translates to bytes could have been worked out. It could be something like 2601:hchsh:eevbo::home/64 for example
That could actually work for the host ID part of the address (not so much the network part). You could do it today with v6 just by extending getaddrinfo() (e.g. with an NSS plugin on Linux).
But L3 addresses aren't the place for naming. They're meant for computers, not humans. DNS supports names longer than 2-8 characters, descriptive hierarchies, multiple address families, other useful info types like SSH keys, and in general operates at the right layer for it.
You currently have an address hierarchy like <AS Number>:<Network Allocation>:<Subnet>:<Host>. That hierarchy is conveniently conveyed in a single 128 bit number. With an alphanumeric address, 128 bits of ASCII would get you `company:office:l` and your net/subnet/host would require more CPU horsepower to compute.
The ascii is for presenting to the user not for hardware processing. It is not a wire format. Onlh when logging or parsing a config (human interfacing) is an ascii conversion required and a modern protocol that wants adoption should prioritize human friendliess at the human interface of the protocol.
Right now the hex lets you mental model the wire bytes nicely but it is unpleasant to use. V4 used decimal which is pleasant to use. UX trumps all.
