Not sure I've been perfectly clear about everything. I think game exchanges should be command driven, not by constantly updating the state of each character. Even holding down an arrow key can be done with "left down" and "left up" or "left" and "stop left" for example. I believe that there does need to be some basic synchronization supported by the server as well as a simple way to deal with latency. But that's a far cry from putting all the game logic on the server.
RE: Cheat ... teleporting as an example. If there is no teleporting command in the game, you won't be able to teleport in the multiplayer world. If someone finds a way to change their local position, it won't show up on any other player's screen. It will just leave the cheater confused.
I'd like to see good responsiveness, but until the activity is making huge bucks, I don't think I'll start an R&D project on the cutting edge of Internet connection speeds. I'm comforted by the fact that photon torpedoes can take as much as 15 seconds or so to reach their targets in Star Trek movies. Cool effect. Why wouldn't you want to see the photon torpedo run its course? With everything from sluggish goofy old canons and catapults to futuristic energy blasters (I've seen it in games already), it's possible to use projectiles that take at least a few seconds to reach their target. And that's more than enough time to sync up.
If the game does larger troop movements, it can take a second or two for ground commanders to respond to the player. I'm not saying that's technically required, just saying it wouldn't be bad to design the game as such. Player / general orders swordsmen to attack the flanks - couple seconds later, acknowledgment from the ground commander. Humans are like that. Why should it not be so in the game? (This can also work if you're giving instructions to an individual character rather than directly remote-controlling it; although I'd have to think more about a game in which that's interesting to do.) It then takes time for the group of swordsmen to move in and fight ... lots and lots of time for sync.
That's just a couple of examples. There might also be some good examples for extremely rapid action play, but I'm just not treating conservative / safe action as what I'm after right now. I'm not against rapid interaction, you understand. And maybe somewhere during the development of what I've described, I'll see an opening, or at least be set for some preliminary timing tests. As I start out though, I don't want to lead game builders astray. I'd rather advise them to do things that we know will work. For those who have the time and interest, ok, they can test the outer limits if they want to. I'm just not going to push someone who just wants to get a good game on the market into doing experiments. I think that's part of responsible support.
And once again ... My WebSocket server is fast, very fast, but WebSockets don't make data move faster over the Internet.