The problem not the order of the constraints as much as the cyclic dependency between your objects' constraints. Blender even warns against it in the system console (in Windows, open through the menu Window > Toggle System Console):

Let's see What is happening when you have a dependency cycle of this kind of constraint. First it's best noting that generally, when you add a copy location constraint to an object, you can no longer set the constrained object's location manually. It will get its location values ONLY from the target object.
Let's say we started with these Z positions:
A = 5
B = 3
C = 0
When we add a copy location constraint form A --> B, A will move to from 5 to 3 since its copying its location from B.
A = 3
B = 3
C = 0
Now let's add another constraint from B --> C.
B moves from 3 to 0, and since A is copying its location from B, A also moves to 0 (this is the same as if both A and B copied their location directly from C).
A = 0
B = 0
C = 0
Currently the only non-constrained cube is C, so you can still move it wherever you want, and the other two will follow it wherever it goes.
But now you add another constraint, from C --> A.
A has a value of 0, which it copies from C. C has a value of 0, which it will now copy from A. Since all cubes are now constrained, you can no longer set their location manually, due to the copy location constraint taking over. And since both A and C have 0, and B copies its location from C, all are stuck in 0 forever and ever ;-)
Bottom line, cyclic dependencies are a bad idea, and if you add a Copy Location Constraint to an object, you can no longer control its location manually.