First of all, there was no documentation whatsoever for the Therac-25, and presumably none for the Therac-20. The lack of documentation implies that there was no information available as to under exactly what conditions the Therac-20 code was supposed to operate. When you want to use anything for a purpose other than what it was intended for, the first thing to do is check to make sure that it was designed to operate reliably under the conditions you want. This is certainly true for software. The reason we write specifications for code is to make sure we use it properly. Without specifications for the functions of the Therac-20 code, there was no way to safely use it with anything other than the Therac-20. So the problem with the Therac-25 was not that its designers reused code, but rather that they reused code unsafely.
The lack of testing procedures was another major problem with the use of Therac-20 code in the Therac-25. The fact that the Therac-20 code had functioned without noticeable failure in the past is a far cry from a proof of its correctness. This is particularly true because of the existence of hardware safety mechanisms that backed up the software in the Therac-20. When AECL decided to remove the hardware safety mechanisms, they should have retested the Therac-20 code to see if it depended on those backup systems. In general, they should have had a full test suite for the Therac-20 code that they could run repeatedly to make sure that the code was correct in the first place, and also correct when used in the context of the Therac-25. The assumption that the Therac-20 code was correct because of prior use can at best be called flawed.
It could be argued, as Leveson does, that code reuse is dangerous because designers assume that old code is correct. Rewriting code forces the author to consider the exact conditions under which the code will be used. However, I believe that there were so many problems with the engineering process of the Therac-25 that rewritten code would have been unlikely to come out any better than reused code. Since there was no real organized testing approach, there is little reason to believe that bugs in new code would be more likely to be found than bugs in old code. I probably needn't even mention how incredibly naive it would be to claim that the new code would not have any bugs in it.
Code reuse has many advantages, the most obvious being that it saves programming effort. Another advantage is that old code has been used and tested, even if only minimally, which is more than can be said for new code. Like modularity, abstraction, and any other software technique, code reuse can cause problems if done poorly. Poor programmers can get in a lot of trouble haphazardly reusing pieces of code, but if they're poor programmers, they're probably not going to be able to write better code themselves. Good programmers should know when it's safe to reuse code and should not be damaged by doing so.