I've found that there are some analogies that are useful for describing agile principles.
Continuous Integration (CI) can be likened to the temperature gauge on your car.
For the most part, if your temperature gauge goes into the red, it's advised that the driver stop immediately and fix the problem with the car. Otherwise the car may overheat and do serious damage to the engine, while bringing the car to an stop FOR the driver. The cost of waiting is significantly higher, and the benefit gained by waiting is marginal at best.
In general, if your CI instance fails you should do 2 things.
1) Assign someone to find out what went wrong (here's a hint, it's probably the person who just checked in code)
2) Chop off the hand of anyone who checks in code on top of a broken build.
Now lets go back to that car. There may be times when you have someone that needs to get to the hospital NOW.
At that point, you may not care how much damage you do to your engine in the process of getting you to your destination. You know that you will pay a heavy price to bring your car back into good shape, but that doesn't compare to getting your deliverable where it HAS to go.
Likewise, if you absolutely positively have to get a particular feature to your customer in the next week, and in the process of this you break your build. An argument could be made to ignore the breakage, and go on.
Personally I don't think it would be a good argument, and exercising that option would be a sign that your engineering practices probably need more work, but the argument could be made.