"Softwaredesigntechnisch" ist man mit der Idee eine Prozedur einem Thread mitzugeben völlig auf dem Holzweg!
Warum?
Ganz einfach, weil die Prozedur ja nicht im luftleeren Raum steht, sondern sie braucht auch Daten, mit denen sie arbeiten kann.
Diese Daten können natürlich in globalen Variablen zu finden sein, aber ich glaube über die negativen Auswirkungen von globalen Variablen wurde schon genügend diskutiert.
Eine Prozedur + dazu gehörende Daten ist aber nichts anderes als ein Objekt.

Anonyme Methoden oder Closures sind im Prinzip auch Objekte - sie bestehen aus der Methode ohne Namen sowie den "eingefrorenen" Daten zum Zeitpunkt ihrer Zuweisung.

Man kann es drehen und wenden wie man will; das was ein Thread tun soll (die "Arbeit" oder der Job) ist irgendwie immer eine Art von Objekt.
Wenn man sauber programmieren möchte, dann lässt man am Besten Objekte auch wie Objekte aussehen und leitet ganz normal von TThread ab:
Im Prinzip ist es ganz einfach:
man muss überlegen, was der Thread zum Arbeiten als Input braucht.
Der Zugriff auf globale Variablen oder Singletons ist tabu; wir übergeben die Daten über ein Property.
(selbst dann wenn die Daten letztendlich in einer globalen Variablen stecken)
Nachdem der Thread gelaufen ist muss man die Ergebnisse abgreifen.
Häufig ist es so, dass die Eingabevariablen gleichzeitig auch Speicher für die Ergebnisse sind.
Dann werden keine Properties für die Ausgabewerte benötigt und wir sind fertig.