Intel is free to dump legacy cruft, they even tried it once with Itanium. However, their overriding goal will ALWAYS be backwards compatibility, so, while Intel MIGHT have the capability to ship a cool and fast 64-bit only Intel processor that ACTUALLY rivals Apple Silicon, they know they don’t have to, because that’s not what their market wants.
First, Itanium really wasn't a x86 replacement. Itanium is aimed at being a HP PRISM , DEC Alpha, Sun Sparc , MIPS (SGI and some others ) , IBM Power & Z-series , Cray Computer, etc. 'killer'. The large server , HPC/Supercomputer market... not Joe Blow's PC that runs email , Word , and web browser. Or some random DOS program. A couple of those targets were 64 bits by the time Itanium got started and all had 64-bit roadmaps. It had extremely little to do with trying to 'cure' the x86-32-bit 'problem' for PCs. Intel wanted to stop the server RISC class processors from getting deeper traction.
It started by killing off HP Prism by getting HP to dump their work to 'join' the Itanium team. Mainly done by accepting the work that HP had already done as the baseline for the instruction set. (i.e., it was
NOT designed
internally at Intel from scratch to be an x86 replacement. ) One down right out of the gate. That quick 'take down' was a dual edged sword because brought some mixed focus. Alpha got squashed in the subsequent scramble (Compaq, new owners of Alpha, dumped it for Itanium) . MIPS also got sidetracked (SGI, major MIP user, dumped MIPS for Itanium ) and stumbled (firmly setting up SGI transition their HQ into Google HQ.) . PowerPC entangled Power and didn't go wide spread (in PC or computers. Windows got looped into chasing Itanium. ). Sparc did OK but primarily stayed single vendor. What got overall was mostly a contraction of vendors at the higher levels using RISC foundations; no broad , influence building coalitions on something outside of Intel's influence.
.
Yes, Itanium has some x86-32 sidecar and/or emulation baggage attached to it along the way. That actually did more damage to Itanium than helped. Adding a modicum on internal, dynamic scheduling to what they had would have helped tons more than that. Marketing themselves as the 800lb gorilla it made sense to use the x86 compatiblity mode as the boogeyman is going to get you factor. Not sure why folks like Compaq and SGI 'bought' that; from a technical perspective is was junk.
In terms of killing off , or at least muzzling, the RISC server family from gaining deeper traction, Itanium did a decent job of carving a path of destruction. There were internal factions at Intel who wanted to move forward on 64 bit extension but those defered. Pragmatically that was good because it allowed AMD to throw a design out there. Intel-AMD cross licensed and AMD got to continue. If Intel had been first AMD would likely be toast right now and things would likely be in a lot worse shape. (Intel likely would have arrogantly stumbled as they did , but there would have been fewer competitors around to put pressure on them to clean up their act.)
More than anything else, they want to be able to “run all of yesteryear’s code” not “last all day on battery” or “run cool”. They’ll always spin a good yarn, they’ll always miss their goals and it won’t matter.
Microsoft dumping 32-bit kernels altogether by 2024 is going to change "all of yesterday's code" metric.
( MS is going to stop selling Windows 10 to folks by the end of this month. Windows 11 only has 64-bit kernels. Yesterday's code set at 2007 by 2027 is twenty years of stuff. It is much longer than Apple's window. ;-) )
All of last century's code at maximum speed really isn't all the necessary for overwhelming vast majority of users.
Intel's 800lb gorilla standing was not solely "all of yesterday's code" ... it was the overwhelming number of PCs. Wintel was the "king of the Monsters" and they even managed to suck macOS off PowerPC and onto the x86-64 juggernaught. It was the variation of the "Nobody got fired for buying IBM" mindset. The herd was all heading to x86 for better line up with the herd or get run over. That's one reason why they were sprinkling x86 pee on the Itanium to use that sales pitch hammer.
The 'attack of the killer PCs' became the attack of the killer handheld. The inertia juggernaut now is an even smaller computer. Intel the inevitable juggernaught is gone. Intel's biggest problem is that they drank way too much of their own kool-aid.
Absolutely no question, no doubt and businesses have GOT to LOVE that fact. And, the x86 ecosystem, as a result, will still be less efficient than the stuff Apple’s producing. Garbage in, garbage out.
Only dubious business buy into drinking too much of that kool-aid. If running the exact same accounting system from 33 years ago you are likely missing out on maximum efficiency. If your business services software stack is 20+ years old same thing. The interconnections between business and the market dynamics have substantively changed in the last 20 years.
Old school Internet Explorer is gone.
Folks who keep dogmatically running the "same old , same old" ( Bed Bath and Beyond. Sears , Soutwest crew assignment system, etc. ) tend not to do well over the long run. Something folks use the "if it ain't broke , don't fix it" as dogma to ignore change. They don't look for 'broke' in a perspective to adaptation to the contemporary business challenges. Setting old criteria for evaluations of old systems in a circular logic set up of "still meets the specs" looking at issues in a bubble.
Sometimes there are corner case pieces of software that can't move because what they are attached to can't move (adapt to change). Wrapping those into a protective blanket ( virtual machine to run OS from jurrasic era or embedding the system behind a protective firewall ) are options. But broad based systems wise to go 20 years and no substantive software upgrades... what are those software vendors doing? Software compilers from 20+ years ago compared to the current ones? It isn't really a contest. What you have is code that is probably not written as well as it could be to run on modern hardware.