Timing was at least part of the problem with Itanium. Arguably, had Merced (or, ideally, McKinley) shipped while the great Internet buildout was going on, Itanium might have made it over birthing pains before the dot-com crash and then been in a position to ward off Opteron and AMD64 when those arrived.
I could argue it was doomed from the beginning as well for various technical reasons given how the industry evolved. But there's at least an argument that better time to market might have been enough to get established as a dominant 64-bit architecture.
Being a couple years late definitely was bad but they also completely blew the performance, especially for ia32 compatibility. Shipping on time would have made the performance gap less bad but I rarely saw it being competitive with what would have been the competition at that time even before you factored cost in. Unless your workload was just Intel’s hand-tuned assembly it was usually cheaper to buy 2 x86 boxes and pocket the difference.
You're absolutely right, hence my hesitancy. IA-32 emulation performance was one particular weak spot. A fellow analyst at the time said something along the lines of "Itanium's IA-32 performance was not only not in the ballpark; it was not in the parking lot outside the ballpark."
Itanium was also, in many ways, designed for a world where ILP, rather than TLP, ruled. That distinction wouldn't become terribly important for a few more years but it would have eventually. Intel made a number of decisions in this vein. See also NetBurst Architecture. (An Intel exec told me, at some point after it had become obvious that multi-core was the future, that Microsoft had really pressured Intel to go down the few/fast cores route.)
I can see the connection. Microsft was even more vulnerable there than Intel.
If we switch from the "Every year the clock rate goes up 30%" model to "50% more cores every year", you're going to trigger the "recompile the universe" event. This is an esistential-level threat for the Microsoft of 15 years ago.
Microsoft's biggest selling point for years was the backwards compatibility. Keep running that old software forever, and the magic of Intel running the clock up means it still gets faster every year.
If that train stops, you may well think "if I have to rebuild anyway to support many-cores, why not do so on Linux?"
Intel initially didn't plan on having fast IA-32 performance. The IA-32 part of the chip was called the "IVE" which was short for the "Intel Value Engine." The thought was that it was enough for the chip to boot in IA-32 mode to be compatible and it was expected that you would set up system state and jump to 64-bit mode as fast as possible. So really it was just meant for compatibility. I imagined it was just a dusty corner of the chip using some old 486 core to take up the least amount of space.
I could argue it was doomed from the beginning as well for various technical reasons given how the industry evolved. But there's at least an argument that better time to market might have been enough to get established as a dominant 64-bit architecture.