You can have rendezvous servers for holepunching on p2p networks. It doesn't solve the case of unpunchable NATs, but I think if one is aiming for pure P2P then it would be sufficient to inform the user about it that it is "blocked by the network" or something like that.
> 2. Peer discovery in pure p2p is SLOW.
I can do random lookups on the bittorrent DHT (6-8M reachable nodes) that yield their first result in 600ms and returned the bulk of the results in 1500ms. Those queries can be run in parallel without significantly impacting latency. The only limit are shoddy NAT devices that have their tracking tables saturated by the traffic.
> 4. You cannot efficiently have shared states in pure p2p without an identity server. That would require the clients to bring their keys with them on every device, not very practical.
Pair devices over local wifi/bluetooth/scanning QR code from screen to camera? Or generate cryptographic identities in a deterministic way from hashed passphrase? I believe ed25519 keys can be created this way.
> 5. In case the network collapses, there is no way for it to go up again without supernodes.
You need bootstrap nodes that can be contacted when the client has no local list of reachable contacts, that's not the same as supernodes.
> Skype abandonned full peer to peer because it does not work if you want something fast, reliable, and feature rich.
Each of those things is a continuum. Yes, certain tradeoffs have to be made if you want a decentralized application. But you're omitting being decentralized and not under control of a single entity as a goal itself.