Think of it the opposite way. You have no coverage, are trying to get a message out and the nearest gateway is miles away. A moving car/train is close to you for plenty of time to transfer a few 100 bytes, and someone in the car/train has a mesh aware widget. It stores a copy and waits to go near a gateway where it upload it for you.

Sure, it's not as nice as a WAN connection, but the average cellular contract is pretty expensive per month. Something like $10 per GB, and often a $30 and up base rate.

So sure, long distance multi-hop mesh stinks for real time voice, but could be quite usable for other use cases.

Ah, but now you're talking about solving an additional problem, delay tolerant networking, on top of mesh networking. This adds a whole new layer of complexity on top of the mesh network, and would probably only work as you say for a subset of services that are made to handle this type of unreliable network.

Also many common delay tolerant network implementations rely on message replication to increase the probability of delivery of the message. This puts additional bandwidth strain on the inter-node hops of the network, which as some of the other commenters pointed out, not actually all that high.

Indeed, seems only practical for things like SMS/IM type traffic where even a Long/LAT + 30 character message every few minutes would be quite useful.

Why would your call be routed just via one single phone?

Are you going to send the message over more than one route? That doubles the required bandwidth over the entire mesh.

You could do something smarter with error correcting codes. Using a rateless code you split your message into an infinite number of chunks, then send these chunks out on your multiple paths, and then once enough chunks have been received you ACK each path. No bandwidth wasted.

I think specifically with voice it should be possible to send two chunks such that if they both arrive then you get your audio, and if only one arrives then you still get your audio but at a lower quality.

This is similar to Multipath TCP, for anybody interested: https://en.wikipedia.org/wiki/Multipath_TCP