Granted it depends on how chatty a P2P system is and how much it depends on intermediate nodes for network assist. Ours is pretty idle when nothing is happening, so it doesn't impact battery life or bandwidth quotas very much.
The best design for a P2P network with more involved nodes would probably be to allow nodes to elect their level of availability to perform network assistance roles. Another alternative would be to build a network with two kinds of nodes: 'large' and 'small.' Large nodes could assist small ones.
It's a solvable problem. To some extent "you can't do P2P on mobile" is a dated idea that came from the era when phones were pretty tiny CPU and RAM wise, networks were slower, mobile OSes were more restrictive to background processes, and the battery cost of things like CPU and network I/O was higher. All these things have improved dramatically in recent (past 1-2 years) phone models. The iPhone 7 and the latest Samsung phones have near-desktop-class processors and radios have become more power efficient.
You do have to do a few things differently. One thing we do is to temporally group / quantize background I/O. Instead of sending packets whenever we feel like it, we do it in longer spaced batches when the network is otherwise idle. This saves a lot of battery power by causing the radio to only wake from sleep once for a batch of routine network traffic instead of waking constantly.