I posted this in response to another thread on this topic but I felt it would be much more visible as an OP than it would be buried in a mountain of replies on the subject.

I used to work for several years as a systems programmer in a data center which hosted several MMOGs. Perhaps I can give a bit of insight into this problem.

The issue everyone is complaining about stems from an architectural design decision made by SE in the early stages of the game's development. The decision made was to design the game in a way which makes the server dictate the live-state of the game as opposed to the client. This is contradictory to the vast majority of online games on the market, presently, as well as in the past. I will explain below the two different methodologies.

Client Live-State:
Most of the game actions are driven by the client. However, the entities and environment are controlled by the server. When you give a command to jump, your client sends a command to the server, which acknowledges, and replies back to the client with a response to jump. Once the communication has completed, your character then jumps on your screen. Say, for instance you are fighting a monster. You attack the monster but your network connection is poor. So what happens is: You send the command to attack. There is a delay in sending the command to the server. The monster continues to attack you (successfully), as it is controlled by the server. When your connection resolves, you finally make your attack. This results in the player's experience being - 'I'm giving commands but they are delayed on my screen.' However, if a monster creates an AoE circle, it will be in real-time on the client because the server sends the command "monster A is doing an AoE attack at such and such time" When your client receives this information, it syncs to the time provided by the server, so the AoE may APPEAR late, but your reaction to it will be on time, because the client is in a live-state. So if you step out of the AoE on your client, when it goes off, your client will tell the server "The AoE landed, but the client was out of it's range", so in the end, even if you are lagging a little bit, you can still dodge the AoE.

Server Live-State:
Most of the game actions are driven by the server. When you give a command to jump, your client jumps on your screen, but in the live-state of the server you have not jumped until it receives your command to jump. So if you're lagging, it may look like you're jumping on your screen, but to the server, you are standing still. This gives the player a false sense of what is happening in the game. So how is this any different than client live-state? Well, for things like jumping its not much different, but when it comes to combat and time-intensive actions, its a whole other animal. Say for instance, monster A drops an AoE. The AoE is live on the server but you're lagging and haven't received the info yet (monster appears to be sitting there). As soon as you get the information, the monster appears to do his cast and the AoE circle appears. The difference is, you are out of sync with the server and the server rules all, so even if you step outside of the AoE, if your client doesn't get the command to the server to update your position before the AoE lands, you get hit by it. And that, my friends, is why you all died to landslide / bombs / any AoE that you were out of on your screen.

The reasons why SE would choose server dictated live-state:
-Prevents desync bugs (on the server)
-Prevents countless potential duping bugs
-Prevents (in theory) teleportation and other unauthorized client commands from being accepted
-If the player has a good connection to the server, little to no delay is observed by the player

The detractors of server live-state:
-Poor connections results in nearly unplayable conditions, specifically conditions which require fast reaction time
-Server infrastructure is more costly (servers must do much more data processing)

In the past, server live-state was extremely rare because internet connections were still poor / narrow-band.

Can it be changed?
Short answer: No.
Long Answer: Technically, yes, but it would be extremely costly and time consuming. SE Would lose millions and it would take months to over a year to accomplish.

I hope I explained things well enough for most people to understand. Let me know if you want clarification on anything.

Cheers.