"4. In some systems you cannot edit some rungs online.
This mostly applies to interrupts, subroutines and rungs with high-speed instructions."
That is why I am so opposed to using Subroutines at all.
The benefit of "Off-Line" programming is that you can screw-up the code all you want without affecting a running process... that is, until you load it into the PLC... at which point, there might be hell to pay!
Until you load the program, you have time to check, recheck, and recheck, over, and over, again, until you have an adequate level of confidence in your code. But even then, if are loading a new, or modified, set of code into an existing process... well, success is not based on confidence alone... your code had better be right!
There is really no way to evaluate what level of stress you should have for any particular change... it depends on the type of change, the devices affected, and of course, your ability as a programmer.
The more complicated the process and the code for that process, the more likely that a programming error can result in destruction of the equipment, and possibly personnel.
I prefer using "On-Line" programming, while the process is running. My ultimate goal might be to install a major change in an existing section of code, but I do so incrementally. As long as the process is currently running adequately, I can let the existing code continue. I then add "Shadow-Code" running along side of the actual driving code. I can watch to see that the "Shadow-Code" is performing as I expect. I can add "traps" to watch for any error conditions that might occur too quickly to be caught by the status screen.
Eventually, I get to the point where I have to let the new code control the actual outputs. First I rewrite the Output code to operate with either section of code. In general, the Output is controlled by either the old-code, or the new-code. The selection is made by use of an ON/OFF Switch in the Output code. The Switch is named "USE NEW CODE", or somesuch. While "USE NEW CODE" is OFF, the Output is controlled by the old-code. While "USE NEW CODE" is ON, the Output is controlled by the new-code!
When I'm ready, and at the appropriate time, I simply Force ON the "USE NEW CODE" bit. Everyone is notified before the switch-over occurs. After doing so, we all continue to watch the process very carefully.
While all goes well, we continue to watch for some period of time (my "traps" are still in place). Eventually, if all stays well, I remove the old-code.
If I run into an "Aw-$hit!", then I simply Force OFF the "USE NEW CODE" bit. Hopefully the "aw-$hit" was just a small problem.
Of course, if I'm adding a new device to the process, that is usually added as one complete section of code, however, it also has an ON/OFF Switch built into the code. FORCE a bit ON to activate the code, FORCE the bit OFF to deactivate the code.
This can be pretty stressful on a running process, but by carefully introducing small changes, one step at a time, major headaches should be held to a minimum. Of course, correct-coding is every bit as important (if not more so) as carefully introducing those changes.
The only benefit that I see to "Off-Line" programming is for developing code for a non-existent, or non-running, process. After all, the process can't be running when the new-program is loaded. There is an exception... if you have a full-blown simulator that simulates your process, then "Off-Line" might be OK... but then, you still have to stop the process to load the new code.
Can you afford to stop the process (production) for every small change that comes along?