Practically speaking,

It depends on your risk management model.

If your system is prone to crashing or locking up, then it might be a better idea to copy the file to another server and do the edits, then load it up to the server and move it into place.

Sounds fishy, however, if your server is so unstable that it is prone to crashing or has such resource problems.

Normally, and I mean everyday on remote, production servers, I copy the file I want to edit and add a ".backup" or ".neo" extension on it, or something like that. But I generally edit the original file and save it to disk when I'm done.

When editing, you are editing a copy in memory, not the copy on disk; so if the system crashes while you are editing, you only lose the changes in the editor, not the file on disk.

I guess, one could say that when you cross the street, you should look right, then left, then up, and then down, and to be safe, look behind you too. However, most of us look right and left. If you want to edit copies and move them that's cool but it is not going to change much in your life compared to editing the original and saving it.

What is important, as mentioned by others and also by me again here, is to make a quick backup copy of a file before . you edit. I do this most of the time, even when I have offsite backups.

Making a copy, editing the copy, and moving it to replace the original file is still "not perfect" because you have still written over your original. You should at least make a copy, edit the original, and save it, knowing you have a fresh backup. If you copy the original, edit the copy, and move it to overwrite the original, where is your fresh backup? You don't have one (in this scenario). Ditto if you copy the file you just edited over the original, you then have two potentially "fat fingered" copies.

So, what's the point? What is the risk? What is the system vulnerability you are trying to mitigate?