Es ist kein guter Stil, später schwer zu verstehen und nicht zu empfehlen, trotzdem erkläre ich wann du das theoretisch darfst, denn sowas wird teilweise auch im VCL-Code praktiziert.
Du darfst nach dem Destroy noch so viel Code ausführen wie du willst, solange nicht auf Speicher des Objekts (z.B. auf Felder) zugegriffen wird. Du darfst also auf keine privaten Variablen oder sonstiges zugreifen sondern darfst nur noch das, was eine Class-Methode auch dürfte.
Du musst demnach auch sicherstellen, dass deine Methode, die das Objekt zerstört, nicht von einer anderen Methode aufgerufen wurde, die später noch auf das Objekt zugreift.
Die VCL löst das so, in dem sie sich selbst eine Windows-Message postet. Der Handler dieser Message zerstört dann das Objekt.
Da Windows-Messages auf Ebene von TApplication.HandleMessage (oder analog) ausgelöst wird, ist die oben beschriebene verbotene Schachtelung in den meisten Fällen ausgeschlossen.
Es sei denn, du schmückst deinen Code mit Application.ProcessMessages (was man aber meiner Meinung nach sowieso nie tun sollte). Denn dann wird die Destroy-Message nicht mehr auf Ebene von TApplication.ProcessMessage ausgeführt sondern dort wo Application.ProcessMessages steht, d.h. evtl. in irgend einer Methode und wir sind wieder beim gleichen Schachtelungsproblem. Tatsächlich ist es möglich, auf diese Art eine Access Violation in der VCL zu erzeugen.
Was weniger problematisch ist, wenn du deine Methode klar als eine Alternative zu Free erkenntlich machst und diese nur "von aussen" ausführst, genau wie Free selbst. Natürlich gilt auch hier, dass du nach dem Zerstören nicht mehr auf Objektfelder zugreifst.
Fazit: Es ist möglich, aber nur wenn du ganz genau weisst, was du tust und gewisse Fälle ausschliessen kannst. Das dürfte dir vermutlich nur gelingen, wenn du deinen gesamten Code wirklich unter Kontrolle hast.
