There is a difference between what you can do in a lab and what you can do in production. The main trouble with our approach was that it was fragile. Very fragile. Extracting accurate program states is a tricky business. Suppose you are working on a C program that just stopped in a debugger. You find a pointer. Does it point to something? If so, what is the C data type of the variable is it pointing to? And how many elements does it point to? In C, all this is left to the discretion of the programmer—and it's awfully hard to guess the memory management used in the program at hand.
Another problem is to determine where the program state ends and the system state begins. Some state is shared between applications, or between applications and the system. Where would we stop extracting and comparing?
For lab experiments, these issues could be addressed and confined, but for a full-fledged, robust industrial approach, we found them insurmountable. And this is why, today, people still have to use interactive debuggers.
The future is not that bleak, though. Command-line tools that implement delta debugging on input are available. The ddchange plug-in for Eclipse brings delta debugging on changes to your desktop. Researchers apply delta debugging on method calls, nicely integrating capture/replay with test case minimization. And finally, through all these automated approaches, we have gained a much better understanding of how debugging works and how it can be done in a systematic, sometimes even automatic way—a way that is hopefully most effective, and maybe even "beautiful."