I tried some experimentation again - it had been a while since the last time - but I think I got it straight again. I like having some running osnaps going - endpoint, midpoint, and intersection are nearly always on. It's too easy to put things in the wrong spot with both running osnaps and tracking enabled all the time, so I generally have POLAR off, and have my Alignment Point Selection configuration option set to Shift To Aquire.
The biggest problem is that running osnaps don't work the same way when POLAR is on as they do when ORTHO is on. The problem is most noticeable with the intersection running OSNAP.
(For the following discussion, let's ignore the temporary tracking thing - assume Shift To Aquire is ON. Things are actually the same when this is set to AUTOMATIC, but get a bit convoluted and more complicated than necessary for this post.)
For example, assume you have the intersection running OSNAP on. If you have ORTHO on, and go to pick a point near enough an intersetion to trigger the OSNAP, you'll get the intersection, even if it violates the ORTHO. OSNAP overrides ORTHO.
However, OSNAP does NOT override POLAR; it works with it. Therefore, you'll get what looks like an intersection OSNAP when your POLAR vector intersects another object. This intersection OSNAP is, of course, visually indistinguishable from any other intersection OSNAP. Therefore, if you try to draw lines to intersections, it's possible you'll pick the wrong intersection, and get a POLAR-object intersection instead of an object-object intersection (or vice versa).
Similarly, I always turn Shift To Aquire on. Otherwise, it's too easy to accidently pick a point along an extension of an object.
There are times when POLAR is very useful. I particularly like having it set to work relative to the last line drawn. But I only use it sparingly, when the task at hand calls for its particular abilities. If ORTHO suffices, then I use it instead, since it's safer, and harder to accidently leave on.
