Security. Consider the following scenario

1. Super-secure process opens private.txt 2. Super-secure process truncates private.txt 3. Super-secure process closes the file. 4. O/S re-allocates those disk blocks just freed by the truncate. 5. Nosy process opens a new file using the recently-reallocated blocks. 6. Nosy process reads through the undeleted data left by Super-secure process and sends them over a network connection to someplace bad. 7. Nosy process writes some random noise to the blocks. 8. O/S deletes the data on disk and then writes the data supplied by Nosy.

There's probably some way the FS could finesse this issue -- e.g., don't actually schedule truncation until you see the first write or close -- but it would be a workaround for buggy applications, not a FS bugfix.