Om du kollar på länkarna @Fläcken postade ovan ser du att EU tack och lov inte anser att man måste harva i gamla spår, den CPU-arkitektur som tas fram i det projektet är RISC-V baserad (de pratar och om en del ARM64 designer).
Har man gammal junk-kod som är bunden till en specifik CPU-arkitektur är sannolikheten väldigt hög att en modern CPU (oavsett ISA) är så pass snabb att man kan ta kostnaden för binäröversättning.
Historiskt har binäröversättning varit ett enormt projekt, men idag (mycket tack vare LLVM och bl.a. Apples jobb där) finns färdiga ramverk för att "bakåt-kompilera" x86/x86_64 till LLVM IR. När man väl fått ett problem på LLVM IR format är det en smal sak att ta den representationen till vilken ISA som helst som det finns en LLVM-backend för.
Rosetta 2 fungerar precis på det sättet, typiskt ligger man på >=70 % av prestanda med binäröversatta problem mot vad man får om samma program kompileras direkt från källkod till "rätt" ISA.
Tidigare har inte fördelar med en annan ISA varit tillräckligt stor + Intel hade under decenier ett klart försprång i tillverkningsteknik och kunde därmed kompensera för ineffektivitet i x86. Idag finns två ISA med väsentliga fördelar över x86, RISC-V och ARM64, samt Intel har inte längre en försprång. En effekt vi ser i detta är att Apples M1 är i bland snabbare på att köra x86 applikationer än vad någon av Intel/AMDs motsvarande modeller är (d.v.s. deras mobil CPUer), men generellt sätt krävs att man kompilerar om programmen för ARM64 för att M1 ska vara konsekvent snabbare än Intel/AMD.
Sedan lär rimligen problemen med ISA vara ett betydligt mindre problem på servers jämfört med desktop. På desktop dominerar program utvecklade i C++ (nästan allt vi kör på våra desktop är C++ program, t.ex. spel, MS Office, webbläsare, videoredigeringsprogram etc). Med C++ kompileras normalt allt till maskinkod.
På servers är språk/ramverk som JavaScript, Java/JVM, C#/.NET, PHP etc dominerande. Alla dessa har gemensamt att de går via ett virtuell lager likt LLVM IR, översättning till maskinkod sker först när man kör programmet -> är ingen låsning till ISA mer än att själva ramverket måste ha stöd för den ISA man vill köra.
De har en egen arkitektur som är VLIW baserad. Ovanpå det finns ett binöversättningslager från x86/x86_64 till den ISA:n, så är möjligt att köra x86 kod.
D.v.s. dubbla hinder... Dels är den en viss prestandakostnad med binäröversättning, dels trodde man mycket på VLIW under 90-talet men det visade sig bara fungerar bra i vissa rätt smala fall. Idag används VLIW i vissa signalprocessorer.
VLIW fungerade helt OK för 3D-grafik, men det var allt annat än optimalt när grafikkorten även började användas för GPGPU... Huvudproblemet är att VLIW fungerar bra när man kod som "kör rakt fram utan villkor", det är rätt mycket vad som händer t.ex. vid 3D-grafik men är långt ifrån typiskt för "vanlig" CPU-kod.