Wenn ich in einem except-Block rumfummle, dann bin ich äußerst vorsichtig und so ein erneutes raise schreibt man ja sehr bewusst - da kann man dann durchaus auch dran denken, ggf. das finally drumrum zu bauen.
Das kannst du bei privaten Projekten relativ leicht machen, aber wenn mehrere Personen an großen Projekten arbeiten, ist das ganze nicht mehr so einfach.
Insbesondere weil du auch gar nicht unbedingt weißt, wo in fremdem Code, auch z.B. in Drittanbieterbibliotheken, Exceptions auftreten können. Genauso weißt du aber nicht unbedingt, dass irgendwo so eine benutzt wird.
Deshalb ist es sinnvoller dies von vornherein abzusichern, dann braucht man sich nur um eine ordentliche Fehlerbehandlung weiter außen zu kümmern. Eben dort wo es Sinn macht. Dort wiederum kann man sich darauf verlassen, dass der Speicher der Unteraufrufe aufgeräumt ist und man "nur" einen definierten Programmzustand wiederherstellen muss.
Und wenn einer der anderen Entwickler irgendwo in einem Aufruf eine Bibliothek nutzt, die vorher nicht da war und die plötzlich eine
Exception wirft, dann wird die zwar vom Exceptionhandler weiter oben abgefangen, aber da in dem restlichen Code die try..finally Blöcke nicht ergänzt wurden, der Speicher nicht freigegeben.
Das sind alles Unsicherheitsfaktoren, die man sich im professionellen Umfeld einfach nicht leisten kann. Code sollte so robust geschrieben sein, dass Änderungen an anderer Stelle nicht plötzlich Speicherlecks (oder Schlimmeres) aufreißen können (soweit eben möglich).