Some users have almost 0 free space on a drive.
Defraggler could have an option to select a drive (or partition) that has a lot of free space for use during defrag.
Though there'd be writing to & from the drive/partition, it would still vastly speed up defrags on drives with very low/no free space.
Users could even have option to select a flash drive with lots of free space, to improve defrag times.
For that matter why not use a temporary ramdisk? Even one of 512MB would suffice. NOT!
The defragging API's in windows don't support using a different drive letter as a scratchpad area, with good reason. File-System integrity. One of the rules & regulations is that the file being worked on must remain on the disk and in a readable format by normal windows operations, all the time, even in the event of a power loss. There are two copies (for the moment) of it and its internal links to sectors and clusters. A "currently being defragged" file is never ever of action. It can undergo read/write ops while in the midst of being defragged.
While I don't recommend you go killing the power while a defrag operation is in progress.. If you did, NTFS would just "re-check" the file and continue on as normal. It would use the last known version of changes that has been verified and committed to disk. So to speak. You can read a lot more on msdn I'm sure. And look up "Journaling File System" to get an understanding why this is a reliable method.
It should be noted that Defraggler, along with the other 20+ defragger tools on the market, use the same API that windows disk defragmenter uses. There is nothing special here, just a fancy user interface.
What **WILL** speed up a defrag operation (and is 100% guaranteed to quiet the thrashing of defrag ops & head movements) is a disk cache program. This will allow a disk to seemingly intelligently schedule the head movements. You get a 50% reduction in head movements immediately. Perhaps more. But heaven help you if there's a glitch in power. You'll loose the file you're working on, probably the adjacent file being pushed out of the way to make room, and a tiny section of the $MFT is going to get scrambled.