Man får alltid vara lite skeptisk när en enda användare rapporterar helt fantastiska siffror, men det är helt sant att eDRAM i dessa hjälpte till en hel del. SweClockers hade ju med den modellen fram till 8000-serien, så SweC kör med rätt långsamt RAM hängde 5775C med 7700K/8400 vilka alla generellt var snabbare än 2600X/2700X i spel.
Effekten av eDRAM är egentligen densamma som att ha riktigt snabbt RAM, något man man se i TechReports test där i5-8400 samt Ryzen 2600X/2700X alla kör med DDR4-3200. 5775C har väldigt snarlik prestanda som dessa, men i detta test är rent tekniskt den långsammaste av dess fyra. eDRAM var vettig i laptops, i alla fall innan LPDDR5, då det är mer energieffektivt jämfört med att högt pressade DDR3/4 kretsar. Men förutom Apple verkar ingen speciellt intresserad att ens betala den extrakostnad eDRAM ger, vilket som du påpekar lär vara mindre än lösningar som HBM...
Precis som @Aleshi skriver är just bandbredd en rejäl flaskhals för integrerade GPUer. Och även om man fixar det kommer man bara slå i nästa flaskhals, kylningen... Både AMDs och Intels senaste GPUer är kraftigt effektbegränsade vid 15 W TDP. U-modellerna från båda dessa har konfigurerbar TDP, från 12 W till 25 W. Mätningar på Ice Lake visar att GPU-prestanda går upp 30-40 % när man ställer 25 W modeller mot 15 W. Sist jag kollade var alla Ryzen 4000-laptops som testas konfigurerade med 20-25 W TDP, det lär behövas för att GPU-delen på något vettigt sätt ska kunna användas samtidigt som CPU.
Det sista är nyckeln! Starka APU/iGPU är definitivt inte bortkastat, men det lär nog aldrig fungera speciellt bra för spel utan det man borde rikta in sig på till 100 % är GPGPU! Även i 4000-serien med 8 CPU-kärnor är GPU-delen ungefär dubbelt så snabb på uppgifter som lämpar sig att köra på GPU. Det förutsatt att CPU-delen kör fullt optimerad AVX-kod över alla kärnor, annars är skillnaden väsentligt större.
Vad som måste finna för att man ska kunna använda GPUn på något vettig sätt är bibliotek och verktyg för att kunna utnyttja GPUn på ett bra sätt. Det märkliga här är att AMD inte officellt stödjer APUer i "HIP" (i praktiken en CUDA-rippoff, vilket är OK då folk känner till CUDA och det är långt bättre än OpenCL). Just nu är HIP Linux-only, men man ska jobba på en Windows-version.
Egentligen alla bibliotek som AMD själva jobbar för att ge GPGPU-stöd använder sig numera av HIP, så för dem verkar OpenCL vara ett avslutat kapitel.
Fördelen med GPGPU är att det finns massor med fall som inte kräver massiv RAM-bandbredd, alla dessa fungerar därför fint på APU/iGPU.
Intel försöker dra det ännu längre med oneAPI. CUDA/HIP kräver fortfarande att man skriver en separat version för CPU och en för GPU, med oneAPI skriver man "vanligt" C++ som kompileras till ett format som kallas SPIR-V (ett öppen format framtaget av Khronos group). Likt GPU-shaders kompileras SPIR-V till aktuellt CPU, GPU etc på varje system. Den stora fördelen (i teorin, vi får se hur det fungerar i praktiken när Xe släpps...) med oneAPI är att man bara behöver skriva en version som kan köras överallt, det går även att samtidigt köra den på CPU och GPU vilket är perfekt för APU/iGPU!
Edit: HIP är API och verktyg. Program skrivna mot HIP kan köras både på AMDs GPUer (då med ROCm-drivers och eventuellt även på något motsvarande för Windows i framtiden) samt även på Nvidia GPUer (då via CUDA).