I use suspension criteria as a back-up to entry criteria and also to ensure you receive an acceptable level of service from other project areas/depts. For example, a development meets entry criteria and you accept it into the test environment. You realise that although the development has met the entry criteria it is untestable/bug-ridden etc. You have specified within your test plan that if X number of severity defects are detected then testing will be suspended until resolved. Similarly, if business requirements are not entirely signed off you could specify that testing will be suspended. It helps protect your precious timescales. I have often seen testing suspended due to unstable code/environments but when communicated to the project team there would be nothing more than a shrug of the shoulders and a "well how will you bring timescales back in?".
Suspension criteria, if signed off as part of your test plan, will help protect your timescales.
I tend to agree with TCPS. The less kind answer is it is "the reasons" we will use to review scope and buy some time when things stop following the plan...
I rarely see these in other peoples test plans but they are worth having, more so in consultancy type roles where payment is on delivery, as they act as a safety net.
The only thing I would add to the good description of TC's is that they are also useful if there is a scope change - this gives you a chance to pull back from test execution and re evaluate what you are trying to achieve.