And that is precisely what the quoted paragraph says. 
Well, not getting too fussy about the "already executing and loaded in RAM" part, the point is - no, it cannot.
If you are executing a program in an environment (LINUX) which contains several threads, you may be able to "kill" a thread, stopping its execution. But even then, that results in "splatter" - there will be shards of the terminated process left in places.
Part of the problem, is that the interrupt has no idea of the process it is interrupting. It works both ways - the interrupt is not intended to affect the process it is interrupting in any way, the whole system is designed that way.
You must code for communication between elements of the process, or entire processes. As mentioned above, the interrupt can set a signal which is interpreted when the main program needs to check on it and will then be in a position to take the correct action to "tie up all the loose ends". If you attempt to sort out those "loose ends" in the interrupt itself, the main program can be confused. If you interrupt a "delay()" call and change things, then what the code sees after the delay() completes will not be the same depending on whether an interrupt occurred or not.
But again, the answer is to use "co-operative multitasking" as described where a delay is not an event but a state defined by a "state variable" or flag. Each time the loop passes through, the delay is assessed by comparing the current time to the time the delay started and if the delay time has expired, then that part of the process advances to the next step.