For all kinds of reductions, mainly code which causes compiler failures.
It is easy to burn a huge amount of CPU time with reductions (large C++ testcases can take a couple of days), it is just important to remember you are saving brain-time, and resist the urge to try to "help" it along.
This chapter actually has a much cooler implementation of delta debugging that what has been discussed here. We're generally thinking of delta debugging in which we take the changes to the source as the search space and use some form of binary search to find the offending change (for which git bisect is great). The chapter in beautiful code begins with this but then moves on to runtime delta debugging in which the techniques are used to compare the memory in use by two instances of the program (one buggy and one not) until a specific piece of the programs state can be isolated as the cause.
It's a fascinating technique -- lots of applications. Andreas Zeller has been doing this for almost a decade now so I'm very surprised it hasn't caught on more.
Is anybody looking at combining delta debugging with Optimizely?
Smalltalk's Change Log is great for this. You can actually just take the list of changes and run binary search for the error, and this will lead you directly to the bug 4 times out of 5. (You can do this with StORE as well.)
http://www.kernel.org/pub/software/scm/git/docs/git-bisect.h...