I firmly support this as a build definition option. I believe that it should be an option that it build in all cases of failure, though that wouldn't be how some of the commenters would choose to invoke it. It might be a waste of resources in many cases, but in several environments I have been forced to work in, the environment was flakey enough that when running the integration tests, they would often fail because a bridge was down, or a tunnel. The tests needed to keep trying until it was up again, and spam certain people until it worked.
This is a slightly different case from what Trygve proposes, because many of these external resources of which I speak are too hard to test... or to put it another way, the execution of these tests IS the proof of those resources, so they cannot be pre-evaluated by reasonable means. In this case, the whole is dependent on unknowables, and should therefore be retried until successful.
Again, I agree that this can be wasteful, and this should not be the only way to configure it. You should, I think, be able to configure it to fail once, try again if detectable upstream dependencies change, or try again until successful. I don't know of any other states for this option.