Odpověď na názor

Jasně CPU hotplug jádro podporuje, otázkou je, jestli je to pro tohle vhodné. Chápu původní smysl toho mechanismu na mainframy, virtuály. Osobně jsem to nepoužíval nikdy s ničím jiným než s hypervizorem, kde pak jde za jízdy hýbat počtem CPU ve VM.
Ale i když to fungovalo, tak to vždy vyžadovalo určitou koordinaci na všech vrstvách. Přidáš CPU do virtuálu, objeví se jako offline, přes chcpu se musí povolit. A nakonec stejně většina aplikací, které si řeší něco s procesy, vlákny to dynamicky nedetekuje. V systému je volání get_nprocs() - aktuální počet resp. get_nprocs_conf() - počet včetně offline. Buď se musí aplikace restartovat, spustit znovu (případ top, lscpu a všeho, co to zjišťuje jen po startu) nebo musí podporovat nějaký vnitřní příkaz aby si za jízdy znovu detekovala aktuální stav (a třeba rekonfiguorovala interní scheduler).
I když chápu, že v hypotetickém šetřivém CPU by byl celkový počet jader stejný a měnil se jen dynamicky počet aktivních. Nicméně i kdyby se změnily aplikace, aby přijímaly třeba nějaké události, tak pořád mi to celé přijde docela heavy handed, na to aby se to dělo třeba několikrát za hodinu.

Druhá principiální možnost je pak, aby se to transparentně dělo v CPU a jen to signalizovalo nějaké stavy do OS. Tam zas vyvstane další otázka, jak to udělat rozumně efektivně. CPU ví o procesech, vláknech a jejich vazbách mezi sebou daleko míň než systém. Což pak plynule dojde k problému jak spolehlivě detekovat idle stavy, ušetřit energii a zároveň úplně nezabít výkon těch aplikací, pokud bude potřeba.
I dnešní standardní mechanismy s C states můžou mít dlouhou relativně dobu těch přechodů mezi nimi (a jestli máš nějaký workload citlivý na latenci, tak je to velký problém a typicky se to úplně vypíná). Vyladění toho všeho dohromady pak i s použitím relativně sofistikovaných mechanismů není úplně snadné. Pokud by se ta jádra komplet vypínala, signáloval se stav do systému a aplikací, bylo by to ještě problematičtější.

Stran té vyšší idle spotřeby, netuším, můžu jen spekulovat. Buď je to s tou aktuální vyšší idle spotřebou tak, že to není u serverových CPU prioritou (což se mi úplně nezdá, že by to vůbec neřešili).
Nebo, pokud to vztáhnu třeba konkrétně na AMD, je to s jejich stávající technologií s čiplety a stále aktivními komponenty v pouzdře okolo obtížně technicky řešitelné. I u současných desktopových Ryzenů je to potíž. Např. jejich malá APU jsou monolitická a mají nízkou idle spotřebu. Desktopový Ryzen 9 s čiplety může mít klidně okolo 40W (a AMD za to dostává čočku :)). Pokud bych to extrapoloval na výrazně větší Epyc, tak mi 70W se stejnou koncepcí nepřijde nereálných.
U těch velkých serverových ARMu nemám žádné podrobnější informace, ale klidně tam může být stejná potíž.