One thing that TOC DOES get right is the need for contingencies. Contingencies have been a part of project planning for a long time. If I read Latin I'm sure that we could find some description of them in the graffiti on the walls of Pompeii or scratched on the stones of the pyramids. At the most basic they are simply a little bit of extra time allocated for all of the unplanned or unpredictable events that may affect the project.
Proponents of TOC claim that their approach is unique because it aggregates all the contingency from each level of the project (claiming that each individual adds some and their manager adds some and then the manager of the manager adds some more) and places it in a single "buffer" at the end of the project. Somewhere that it can be watched over easily and since it is on a high shelf, individuals won't be taking some "just in case". I'm still not sure how this is any different from the usual.
One area in which TOC has a shortcoming with contingency is in how it is calculated. The implementations of TOC that I'm familiar with take the critical path and put a buffer at the end of it (based on the underlying variability of the tasks within that path). So far so good. Then they examine the schedule paths which feed into the critical path and place a buffer on them.
The problem with this is that the tasks on these feeding chains are double buffered, sometimes to the extent that the resulting schedule no longer makes logical sense.
Let me explain by example. Consider a schedule with 8 activities. The critical chain is A,B,C,D,End
There are three activities X,Y,Z which are parallel to A,B,C but are just a day shorter in total duration. The TOC software puts a buffer after End equal to some percentage of the task variation of the sum of A,B,C,D,End. Then it inserts a buffer between X,Y,Z and D. The result is that X is now scheduled to begin before A. This makes no sense to people on the project and they begin to doubt the validity of this approach.
Instead of inserting buffers by rule (a rule we have just shown to be odd if not invalid) I think it is better to put contingency where it belongs and to derive the PROBABLE critical path using techniques like Monte Carlo simulation. This way you are dealing with a better set of probabilities (it requires no more inputs than TOC) and in the case of multiple near critical paths it can point out which paths require close attention and which are closer to being a "sure thing". For more on Monte Carlo schedule simulation you can check out a macro I wrote which does monte carlo simulation in Microsoft Project.