On Windows, the resulting file is guaranteed to have any intervening bytes zero-initialized, but for DOS, that wasn't always the case, and any thus-created file could recycle previously deleted data, especially on redirected filesystems (e.g. LAN Manager or Novell NetWare volumes).
It definitely is a problem if a network server extends files that way!
NTFS has a "zero fill" flag that the OS sets for newly allocated blocks, so it doesn't actually have to fill them on disk - it can just return zeroes when an application tries to read from a part of the file that hasn't been written yet. I believe ext4 and all other modern filesystems have this optimization as well.
That depends: if the operation was on a floppy you got from someone else, that data might very well be theirs.
> NTFS has a "zero fill" flag
True, but irrelevant: the Windows API guarantees the "seeking to an offset greater than the file length and then writing anything, including nothing, will fill the intervening bytes with zeroes" behavior. How this translates to the underlying file system (which may very well not be NTFS) is an implementation detail.