It is not the creep age, but rather depends on the execution order of the creep actions.
If you are looping over Game.creeps (which probably a lot of people do), you will have the insertion order which of course directly correlates to the age of your creeps.
Have a look at the following Game situation:
Preconditions:
3 creeps (owned by you*): An attacker (A), the target (T) and the healer (H). All actions executed are considered valid (correct range, etc...), and thus should return OK.
We will look at two execution orders:
A.attack(T);H.heal(T);
and
H.heal(T);A.attack(T);
*This is a somehow simplified scenario, because in most cases attackers and healer will belong to different players, thus you cannot influence the order of the creep actions.
Scenario 1:
T.hits === T.hitsMax, A.attackPower < T.hits
The result of execution order 1 will be, that A successfully attacks T and then H successfully heals T.
Now with execution order 2 (again, assuming, that T had full health at the beginning of the tick), A will attack T, but H will not heal T (since it had full health when the "heal" was scheduled). Notice, that still, all of those action return OK!
Scenario 2:
Changing the preconditions to T having hits<hitsMax:
In both cases H will heal T. Both execution orders will leave T with the same hits at the end of this tick.
Scenario 3:
T.hits === T.hitsMax, but A.attackPower > T.hits (= T would die next turn).
In both cases, T will die without H healing T. In the first execution order H does not heal, because T still has full life, in the second one, T is already considered dead.
Scenario 4:
T.hits < T.hitsMax, A.attackPower > T.hits, but A.attackPower < T.hits + H.healingPower
Execution order 1 has H healing T, A attack T, T survives another tick
Execution order 2 has A attacking T, T dies, H cannot heal T
The tragic thing is, that all those creep actions will return 0 (OK) which does not reflect the actual success of the actions (both, the very first and very last scenario should more precisely result in some kind of INVALID_TARGET for the heal action. The first one, because the creep has full health, the latter one because the creep is already considered dead).
A possible solution for this specific attack/heal problem would be to remove specific [full HP|dead] checks during the tick and rather calculate the state of a creep at the very end of the tick, after all instructions are processed. Then if the creep has hits>hitsMax, hits will be capped at hitsMax, and if hits<0 the creep is considered dead.
Downside of this approach would be, that you have to manually watch out for overheal/overkill, while the current approach somehow handles this for you.
However, this does not cope with race conditions that occur in other places like movement, resource management (harvest/repair/build/transfer,...) or certain structural actions.
Personally, I think that the the current system looks fine to me, because in some cases you benefit, in others not. On average I think, benefits and drawbacks even themselves out.
What you can do, build a Set (which per definition obeys insertion order!) and fill it with you Game.creeps weighted by a certain order you define, rather than the creep age.
let myCreeps = new Set( /*insert Game.creeps ordered by your personal preference*/ );myCreeps.forEach(function(creep){ /* do creep actions */});
Or you could execute the creep actions in certain groups (first all workers, then attackers, after that healers,...).