Your own example actually demonstrates how a client-server architecture is much better.
"better" for what? when clients have dial up connection? even then, it only limits the maximum number of peers per game. client/server model is simply byproduct of bandwidth constraints of the past.
1) Your reasoning here is slightly off. Yes, a round trip to and from the server would actually be about 42km. However, you're looking at this as a 1:1 relationship. What about the other 3 players that also get updated? The distance covered here is now only 21km. And the server sends out updates frequently with or without client input in most cases, so that's 21km for all players.
for the full frame to complete you have to send AND receive data, unless you are only spectating the game. ideally packets from all players should arrive in about the same time, but since this never happens in practice the server has terrible choice to make - to wait for sync or just continue. most of the games actually wait, so return trip does not only take more because of the plain larger distance, but you have to wait on "slowest connection", and then it takes time for server to process all that, and then the info has to come back to clients, and only when this frame is finally rendered, only then we can stop the watch and see how long did it take.
2) Bandwidth plays a very important role on client machines. Most ISPs loath when their subscribers use upstream bandwidth, especially on cable networks that are not designed for that behaviour (sad, but true). Residential networks have roughly a 1:20 to 1:10 upstream to downstream ratio. Dedicated game servers generally have a 1:1 ratio. So when a client only has to send a couple bytes out and receive larger packets from a single source, this is a good thing. You also have to consider congestion. Someone connected from a dense area like LA is likely to run into a lot of congestion issues compared to someone connected from Idaho.
why do you care about ISP? you pay for you bandwidth and you should be able to use it as you wish, just like you do. download/upload porn all they long if you wish, no one should care, but if they say something, spit in their face and change ISP.
if i can upload my photos and movies, if i can watch and listen streaming multimedia, watch youtube all day long, using my full upload/download bandwidth, then why do you think it would be a problem if the same amount of bytes is streamed for the purpose of the game? if people can exchange billions of illegal gygabites through p2p networks using they full up/dwn bandwidth, then the same should work for the game. isn't that so?
There is also the matter of bandwidth caps now happily employed by most, if not all, ISPs today. Have you ever seen how much bandwidth a game like Battlefield takes up? Let me tell you because I analyzed it, among other games. In a 32 player game, a single Battlefield client consumes up to 32KB/s. That's a damn lot for a single user. 32Kb x 32 players = 1MB/s from the server, which is exactly what I recorded when hosting a 32 player game. I doubt any residential line supports that sort of bandwidth and even if it did, you'd hit your caps quite quickly.
would you rather play a game for 5 hours on 20Hz, or 4hours on 60Hz? the bandwidth difference is not that big. for some people "better" is cheaper regardless of quality, for others "better" is better and they feel it is natural for it to cost more, that doesn't make it worse, only more expensive.
3) Not true. P2P has every more reason to cause delay issues. As I mentioned in 2), ISPs limit residential upstream. Have you ever tried to host a game server on a cable connection? You would get at most 6 players, each with a latency of 100 ms. I know, my friends and I use to host games all the time. A P2P model means everyone is a client and a server, so each connection has the 6-player limit too.
there are no delays in p2p caused by bandwidth, only if you setup the situation where clients would actually exceed their bandwidth. but even if all the clients had dial up, then they would merely be limited only with the number of peers that can be in one game at once, say 4... but if they have some average ADSL, then 16 or 32 players should be able to play without a problem, on 60Hz or even more. while server based approach can never achieve 60Hz with any of the clients, not even over LAN, maybe.
also, there is a neat thing you can do with p2p. just like servers can send updates to client only about other visible client or just of those that are nearby (in the game-world)... well, peers can do the similar thing much more elegantly, they can communicate on different frequencies depending on the distance. so if some peer is far away, in the game-world, you can send packets to that peer on much slower frequency, therefore drastically reduce bandwidth. you could send updates to peers that are out of visual range(in the game-world) on even 1 second intervals or slower, and increase the frequency dynamically as they close by to your field of view, therefore being able accommodate for all kind of connections on the fly, as a simple change in frequency could allow to switch from 'more players' to 'more frames' as desired.
Also, when someone connects from far away, say China, then all other players have to send a signal out that distance. That's an accumulated distance to China _and_ back causing all the more interruptions and delays whereas in a server model only the server has to deal with such a far away client. The dedicated server is also going to have state of the art networking, so it's likely the connection won't suffer as bad.
distance is distance, and having a server only makes it worse.
there is no FAST/SLOW here, no waiting - you only have FURTHER and CLOSER, and further is not SLOWER it is only more behind in the past, but the rate of update is NON INTERRUPTED, has CONSTANT streaming flow. theoretically working on FULL 60Hz and more, where frequency only depends on upload bandwidth, size of packets and number of peers. there is no lag, no glitches, no slowdowns, no waiting on server... only time dilation, depending only on DISTANCE.
imagine 8 people have radar devices that can read signal from similar device and display their location. all of them broadcast their location to all other and all the devices update location as the the signal arrives. now, this signal never stops and the latency here is directly proportional ONLY to distance.
again, latency does not mean SLOWER, only further back in the past. but even the stream of data from China to Italy, or wherever else, would have update rate as much as the bandwidth allows, easily 60Hz and more.