I use NAT traversal for Firestr (http://firestr.com) back in 2013 though this is still cool because of the ICMP hole punching. I'll have to see if I can incorporate that.
P2P requires knowledge of the peer's IP, which can be unwelcome depending on the messaging partner (and it's hard to make a config for do you trust this person enough to see your IP: yes, no, only if I'm on network X, not if I'm on network Y, etc)
P2P requires both nodes to be online simultaneously, so it's difficult to make work well for asynchronous messaging with smart phones or mobile laptops or desktops that are regularly turned off. Maybe you remember how Skype used to be?
So, I think you definitely want a server based store and forward messaging path to ensure delivery and for (optional) privacy from peers, and adding an optional P2P path is additional work, without a lot of gain; at least if it's text. When you start sending media, the bandwidth/storage savings from going P2P make it worth exploring.
While this is an interesting concept, the hard part in NAT traversal is getting it to work on all the possible NAT types. In particular, I believe that this method doesn't work for symmetric NAT devices, which are widespread in corporate environments. It's not a surprise that this idea from 2010 didn't take off, ICE/TURN are still kings.
 These devices assign a different port for each destination address, and this ICMP method doesn't help predict the port that will be assigned.
Edit: they are filtered. Suspicious names go to 127.0.0.1
(connecting a usb-modem is much safer, I'd have to actually spot the device which would require getting out of my chair... ;)
But also this technique doesn't depend on ICMP that is just what the example happens to use. Pwnat itself uses only UDP for outgoing requests.
Or to phrase it more generously, NAT is an ugly but simple hack that allowed the internet grow despite limited address space and without a gigantic investment in hardware to support an over-engineered replacement protocol.
And yeah, I've dealt with segmented memory models, in C and ASM. I don't think the situation is very comparable at all, nor are segments as bad as people say, but that's neither here nor there. I mean, FFS, all modern systems use an MMU that remaps memory addresses between processes anyway.
Almost every piece of hardware sold since 15 years is compatible IPv6. There is no need of any "expensive hardware".
The main reason that IPV6 never lift off is the lack of interest, lazyness and no will for configuration.
> lack of interest, lazyness and no will for configuration
Is a symptom of v6 being over-engineered.
The only other significant change from V4 to V6 is the use of multicast instead of dumb broadcast for V6's equivalent of ARP on LANs. That's an improvement as it allows smart switches to more easily scale address lookup.
"Does the server have to specify the client host?
The server does need to have any unique prior knowledge about the client. "
Should that read, "The server does NOT need to have any unique...." ?