That would only take in to account the state at the time the path was calculated, and changes while the object is moving along would be ignored. It also would not take in to account other object's plans to move through there, meaning sending 20 objects off at once will promptly traffic jam them all in the same place. Taking in to account dynamic changes and other object movements would probably have a high performance overhead, and is difficult to implement given actual pathfinding happens in a separate JS context on a web worker.
The RTS template already avoids stacking at the destination by maintaining formation. I don't think adding delays would make any difference.
Your solution to head-on blocking does not work in the general case: if two objects wedge together beside each other (e.g. both trying to squeeze through a gap), both turning the same way will continue to jam them even worse. So one blocked evasion strategy is not enough: you need to take in to account their relative orientations, and possibly even the other surrounding objects, to know if they do in fact have room to do anything. I mean consider two objects hitting head on down a narrow alley - there is no room to turn, so they must reverse instead. If it detects the wrong thing, it will likely jam itself in an even worse position and may even get permanently stuck. This is far from simple.
I have spent many hours on this in the past and it seems pretty intractable to solve in the general case. Depending on the cell size is also a bad idea, since you might want to adjust that for performance or detail reasons. That's not to say it could be better, and I will try to come back to this and figure out some ways of making it easier to deal with, but I think it is far, far more complex a problem than you appear to appreciate. Objects moving through each other looks wrong, but actually works really well, so there's that.