0.03125 gives you 32 runs per second.
0.03 gives you 33.3... runs per second.
The different results with order cancelling might be due to the differences in timing relative to game update frames. It seems that JASS timers interrupt the inter-frame period to run JASS which is why they have such a high precision (sub game update frame). This is very different from StarCraft II timers which are run as part of the game update frame which is why they have a low precision (to 1 game update frame).
Some people even say they see a difference with 0.01, i mean the mouvement seems more smooth (at least one reliable guy said that).
That is because Warcraft III usually renders at 60 frames per second. Anything slower than a period of 0.01666 will visually skip at least 1 frame per second (appear in the same position for 2 consecutive frames although things around them will have changed). Humans can easily see the difference as there is no motion-bluring so a huge discontinuity in motion is created, especially relative to other motion.
Of course this is only a problem if the game is being played at 60Hz refresh rate. If the computer lacks the resources to run the game at 60Hz or if an unusual display is used with a slower than 60Hz refresh rate then longer period values can be used. Poor quality displays might also be unable to represent motion at 60Hz properly resulting in an inability to tell the difference between the two.
However the fact remains, there is a huge visible difference between 0.03125 and 0.01666 periods.
0.03125 is used purely because it gives you 32 updates per second. This is a nice whole number that is a power of two making it very easy to use and calculate stuff accurately.
Personally, movement systems should be dynamically duty-cycled so that they will run at a full 60 frames per second when only a few objects are moving but then decrease in frame rate as the number of objects increase. Most of the time you will only have a few objects having to be moved so 60 FPS is not unreasonable and will give you impressive visual results. During the occasional times of peek activity you throttle the frame rate back automatically to prevent performance problems and since there is so much activity and only very briefly it is unlikely the player will notice a difference. After the number of moving objects decrease you can crank frame rate back up to 60. It also could scale better than current fixed period implementations as you could drop the frame rate considerably lower (eg period 0.05 for 20 FPS) in an abnormal situation where you need hundreds of moving objects. You could also avoid spike loads when updating by splitting the update job across several frames (sort of duty cycled).
A simple example would be 100 updates per second where each update can move 20 objects. This would mean 20 objects would update at 100 frames per second but 40 objects would only update at 50 frames per second and 80 objects at 25 frames per second. Obviously this would be the most simple to implement example which is probably not suitable for real use. A better implementation might adjust the objects per update and update period based on the number of objects and could also have a maximum and minimum update period value.
