I can imagine any number of situations where it might be wanted. Keep the file open in vim, changes are made from somewhere else, but you'd like to keep the original version, so you :w. It makes sense to me the :write actually writes regardless of context (assuming sufficient permissions) and with no hidden conditions like "something must have changed". That kind of thing leads to weird user behavior like editing whitespace just to be able to re-save a file.
Vim is from an era when software was written to do exactly what you commanded it, not what you intended. It was your responsibility as a user to learn how to turn your intentions into commands.
Unfortuantely, too many modern programs are not designed to do what you commanded it and try to believe they know better than you do (which is often wrong, anyways). (The other problem is often not designed that expert users can use and can be programmed and used with other programs (e.g. using pipes).) I think that vi is better, in this way; it does do what you commanded it, and can be programmed and used with pipes, so it is better.
Nevertheless there are such thing as adding a confirmation message in case of a dangerous operation (and, if necessary, and option to disable such warnings). For example, C compilers usually have warnings, and you can disable any warnings that you do not want.
There are strange cases which may make this a logical choice. Since vi doesn't traditionally lock the file it's editing, another process could change the file on-disk while you have it in the editing buffer. I think you'll get a message in these situations, because it's usually not what you want. Then you'd have the choice of writing out the buffer, whether it's changed or not, to restore the contents of the file from when you began your vi session.