Zero length files were a possibility in ext3 for the truncate & overwrite scenario already. They were probably rarer, but certainly possible. The patch should make them equally rare in ext4 (unless you disable it). In any case anyone writing for Unix/Linux should know about and use at least the rename trick for replacing small files. Not doing so causes much worse problems than this one.
Zero length files were probably not possible (or at least so rare that you'd never see it) in ext3 for the rename case if you have data=ordered. The patch makes them similarly rare in ext4.
Neither happens if you run normally, or even if you soft hang, losing interactivity but allowing the kernel to flush to disk. Neither happens if your laptop doesn't wake up from sleep so long as the sleep code properly calls sync(). Neither happens if your changes were at least 5 seconds old (ext3 data=ordered) or 60 seconds old (other cases) The people getting bitten either lost power suddenly while working, or hit the reset button.
I agree that zero length files are undesirable, and shouldn't be common even if you pull the plug. Evidently Ted does too, since the patches are enabled by default. Still, it remains the case that applications which must have data integrity need to be more careful than this, because otherwise things can (even in ext3 with data=ordered) go badly wrong for you.
I believe that nodelalloc is just as much overkill as fully preserving atime is. Sure, in theory it might be slightly safer to disable the delayed allocator, but in practice it doesn't make enough difference to worry about, and the performance gain is very attractive. Sooner or later if you use computers you will lose some data, that's why we have backups.