Basically the difference between connecting to datacenter-residing apps that internally share data between each other and connecting to 10 random guy's basement PCs.
Everyone who played any P2P multiplayer shooter in their life knows P2P sucks... on the other hand, dedicated server based shooters and MMOs (generally) work great. You don't have to be an IT professional to know this. Similar concepts (speed of light and multiplicative effects of multiple slow connections) apply here.
P2P is only great for uses where latency doesn't matter. See: Torrents.
That's too broad of a generalization. p2p is AWESOME for latency since every server added adds latency.
What you are talking about are probably p2p networks with multiple users (based on your shooter reference) and the problem is of home connections and bandwidth since multiple users that all need to connect to everyone doesn't scale.
So for your example:
One on ones over p2p are optimal, but p2p matches with more than 8 players are suboptimal (I pulled the number out of my ass it depends on the protocol and usecase)
It is both decentralized and distributed. It's not P2P though, it's a hub-and-spokes architecture with several interconnected (federated) hubs.
Hubs can have decent uptime and thick internet connections. Hubs are relatively few so they replicate state quickly between themselves, and then more locally between spokes when they come online.
Most natural structures are more tree-form, like that.
That just depends on how you define "distributed". If it means "running on multiple machines", then even centralized protocols are distributed, since a part of the computation is running on your computer.
In context of protocols like Mastodon, if the end-user devices aren't primary holders of data, then I don't call it distributed. It's just decentralized. I guess that way, "distributed" necessarily implies peer-to-peer.
