Wenn das so ist, ist entweder der genutzten Algorithmus nicht gut parallelisierbar oder die Entwickler (das projektmanagement) hatten früher keine Lust dazu.
Nicht jeder Algorithmen kann beliebig parallelisiert werden. Das Neuformatieren eines großen Word-Files wird immer nur auf einem Thread laufen können. Bei Handbrake hängt es vom Codec und der Bildgröße ab, ob der bei mir 8+8 Kerne ausnutzen kann oder nicht.
Der Core-i 4xxx ist schon eineges älter wie 2 Jahre. Wenn die Software erst 2 Jahre alt ist, dann kann sie durchaus Befehle nutzen, welche der core-i 4xxx noch nicht kannte und welche erst auf neueren CPUs aktiviert werden.
M.M.n. hängt das mit dem geänderten CPU Design zusammen.
Die Zeiten, in denen für jeden CPU-Befehl festgelegt war, wie viele Taktzyklen die Ausführung dieses Befehls benötigt, sind schon lange vorbei. Die Befehle werden intern in Mikrooperationen zerlegt, zum Teil parallel ausgeführt und das auch noch (mehr oder weniger gut) spekulativ. Wenn es also in der Software eine Verzweigung gibt, die in Abhängigkeit eines Rechenergebnissis mal links oder rechts herum läuft, dann werden u.U. beide Wege schon ausgeführt, bevor die Entscheidung für "links" oder "rechts" bekannt ist (so lange die Daten dies zulassen). Ist die Entscheidung bekannt, wird der nutzlos ausgeführt Pfad verworfen.
Das ist u.U. eines der Probleme bei den Spectre/Meltdown Bugs, weil Daten aus Geschwindigkeitsgründen nicht gut genug gegen einander abgeschottet waren/sind.
Und nun kommen die neuen Prozessorgenerationen ins Spiel. Dort wird u.U. die Anzahl der spekulativ bearbeitbaren Mikrooperationen geändert, die Entscheidung, ob die CPU spekulativ etwas ausführen soll, wird optimiert, es werden mehr Ausführungseinheiten für die Mikrooperationen eingeführt usw. Und dann kann manchmal der Hersteller auch noch die Ausführung gewisser Befehle beschleunigen.
Bei Zen2 hat AMD z.B. die Bandreite für Fließkomma-Berechnungen verdoppelt (insb. für AVX256) und auch bei den Interger-Einheiten wurde einiges optimiert:
AMD Zen 2 – Alle Details zu Ryzen 3000 - ComputerBase
Genauso wurde dort an der Sprungvorhersage gearbeitet, womit (hoffentlich) nicht mehr so viele Befehle spekulativ, aber am Ende nutzlos ausgeführt werden müssen und die Ressourcen für andere Dinge bereit stehen.
Da in der Regel nicht nur ein einziger Thread läuft, teilen sich (spätestens bei SMP) die Threads gewisse Ressourcen. Dazu kommen unterschiedliche Cache-Größen und die Hauptspeicheranbindung.
Passt das alles "irgendwie" zusammen, wird die unveränderte Software selbst dann auf einer neuen CPU schneller ausgeführt, wenn sich die Taktfrequenz nicht ändert, theoretisch also gleich viele x86-Befehle pro Sekunden abgearbeitet werden "sollten".
Passt das ganze aber nicht zur (alten) Software, da diese z.B. auf eine festen L1/L2 Cache-Größe optimiert ist, dann kann das auch zur schlechteren Performance führen. War z.B. eine Software für die 64 KB L1-Cache des Zen1 optimiert, so könnten sich dadurch beim Wechsel auf Zen2 mehr Speicherzugriffe ergeben, was wiederum zu weniger Performance führen könnte. Andere Optimierungne von Zen2 mögen das wieder auffangen, womit am Ende exakt diese Software "nur" gleich schnell läuft wie auf Zen1.