Now say you have a unit in your game that fires a cannon with a certain cooldown. The reason it can't fire continuously is because it has to reload. This is represented by an animation. But the server also needs to be aware of the cooldown so you end up having to sync up the animation duration and the cooldown that the server understands.
The server awareness is primary and the first concern. The most important thing is that the right thing happens and only the server may decide that. The only thing it should ever believe the client about is the user's input. I know you know that but that has to be stated.
So, assuming your proposal is that the animator decides the timings and this information is passed to the server-side developer... you have simplified nothing and the code is still "duplicated". The server application still has to enforce the cooldown. The code still has to be written. It may be worse code than it would otherwise have been and it certainly will be more fragile because it has been dictated by a graphic designer's imagination and not the internal mechanics of the game. It is not simpler.
If the proposal were that the client application tells the server "I finished reloading, I'm firing again now" then you have handed your application over to the hackers. You have created a game where the user can toss a coin and decide whether or not it came up heads, then demand money from the NPC gambler who has "lost" the bet. Even if the user is not a cheat, remember that MMOs suffer from lag and that the client software also suffers from the load on the client computer (maybe some auto-disk-defrag task decided to start up). It can neither send reliable timings back to you nor reliably show to the user what is happening now. Which feeds into my next point...
Code duplication? The server application decides what happens, based on a combination of what the user has requested to happen, what the game dictates will happen, what events and conditions are providing other inputs (NPC activity, other user activity etc) and what the application will allow from the product of all those. The client just tries to present a plausible representation of what it has been told is happening, wrapped in a lot of glitter which has no existence in the actual game, having told the server what the user wanted to do (move forwards, swing a sword, change to secondary weapon, whatever). These are completely different tasks.
The game world "exists" in your servers. The player is trying to "live" in that world from his or her home computer. The player cannot do that (and will not want to play any more) if the representation of game events is not both plausible and consistent. They can live with a game where sometimes things get too laggy and slowed down (as in a huge multi-player raid/battle) for them always to see that they have run out of ammo - if the game is reliable in managing those events. They will not stay in a game where they may seem to have reloaded and be firing, only nothing is being shot. They will not trust such a game to manage any event, server side or not.
So for your game to be acceptable, some code duplication is essential. Client side developers/animators must know something about what is going on server-side, because they have to stay roughly in sync with it under very demanding conditions and make it believable and acceptable to the player. You are trying to make the same world exist in two widely separate places and in two separate applications which absolutely should not share any code (for reasons of security as well as simple separation of concerns). Try doing that without repeating anything. Duplication of the essentials of the game is the whole point.