Zu 1. und 2.: dies halte ich für ein Gerücht, alles lässt sich optimieren und sei es, die SQL's in Einzelschritte zu zerlegen.
Oft genug habe ich erlebt, dass Join-Beziehungen mittels temporärer Ergebnistabelle (create qtemp/mytemptable as select ...) um Faktoren schneller sind. Mitunter von Minuten zu Sekunden!
Man bedenke, dass eine CTE/derived Table/Scalarer Subselect keine temporären Zwischentabellen ergeben sondern je Quellsatz zur Ausführung kommen.

zu 3.: Klar, wenn man bei 1 und 2 nichts findet, landet man bei 3 was nicht wesentlich was bringt sondern nur Geld kostet.

Und was die ominöse Prio angeht, so betrifft dies die "Häufigkeitsverteilung" auf der sog. Zeitscheibe.
Bildlich gesprochen erhält jeder Job über die Prio entsprechende Anteile. Je mehr Job's im System, so geringer der %-Anteil. Zu verstehen ist das wie die Anzahl der Tortenstücke die durch die "Anzahl Jobs" * (100-Prio) berechnet werden und gleichmäßig verteilt sind.
Jeder Job bekommt so eine definierte Ausführungszeit.
Bei jedem I/O oder sonstigen Wartebefehlen wird die Zeitscheibe vorzeitig abgegeben, der Rest verfällt und genau davon lebt das System eigentlich.
Wenn ein rechenintensiver Job seinen Zeitanteil nun voll ausschöpft, leiden alle anderen Jobs, die ihren Anteil vorzeitig aufgeben, extrem darunter.
Wenn also bei z.B. 1000 Job's nur 1 einziger Job etwas weniger häufig dran kommt, seinen Anteil aber ausschöpft, ändert das am Gesamtverhalten des Systems nur unwesentliches.

Bei Systemen mit wenigen Jobs (ich meine hier < 100) kann es da schon Auswirkungen bringen.

Ggf. interessant ist eher "Zeitscheibe in Millisekunden", Dialog z.B. 2000, Batch 5000!
D.h., wenn ein intensiver Rechenjob eben ohne IO-Unterbrechung 5 Sekunden rechnet wird er danach zwangsunterbrochen.