This isn't an NTFS thing. The I/O Manager implements NtLockFile. Applications can request exclusive byte-range write access to a file. And perhaps it is lazy programmers, or defaults, but they generally do.
I don't think Microsoft sees client machine reboots as an issue, and it used to be much worse when they used to be released weekly. On the server side, Microsoft expects that you'd implement some form of high availability.
NTFS on non-Windows follows the locking semantics of the underlying driver model/kernel, e.g. you can replace an in-use file on Linux. Likewise, using FAT on Windows you cannot replace an in-use file. This is just to demonstrate it isn't a file system-specific "issue" (if you feel it is one). It was a design decision by the original NT OS/2 development group.
Ultimately, the NT byte-range locking is a holdover from NT OS/2, where in OS/2 byte-range locking was mandatory.
I don't think Microsoft sees client machine reboots as an issue, and it used to be much worse when they used to be released weekly. On the server side, Microsoft expects that you'd implement some form of high availability.
NTFS on non-Windows follows the locking semantics of the underlying driver model/kernel, e.g. you can replace an in-use file on Linux. Likewise, using FAT on Windows you cannot replace an in-use file. This is just to demonstrate it isn't a file system-specific "issue" (if you feel it is one). It was a design decision by the original NT OS/2 development group.
Ultimately, the NT byte-range locking is a holdover from NT OS/2, where in OS/2 byte-range locking was mandatory.