That's (UX) my biggest concern, honestly. UX is just too important, and it's becoming an increasingly fast moving bar. Simple things like hitting up arrow to edit your message, to more complex things like stickers and gifs, these are (unfortunately) requirements for me in my peer circles.
They sound silly, i know, but Telegram has (mostly) a great UX, and for such an important tool i can't currently give up features.. let alone convince my friends to likewise give up features.
(Fwiw, i love Matrix in design)
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.