I'm not sure it was ever going to happen.

Itanic is just the latest in a long line of architectures that include the caveat "well, yeah, that's a problem but the compiler will make up for that". While compilers have measurably improved over the last 30+ years, the magic compiler tech that makes things like Multiflow Trace, Cydrome or Itanium performant enough to make a difference in the market hasn't materialized. It isn't that the compiler didn't 'happen in time', it still hasn't happened.

What really happened was that cache misses kept increasing in latency (CPUs getting faster, memory isn't) and static scheduling simply cannot scale that far. Multiflow and friends would have exactly the same problem in a modern implementation - static scheduling is fundamentally hopeless.

Transmeta did slightly better as CMS (the "JIT") could take advantage of biases discovered at runtime, but still couldn't do as well as a fully dynamic scheduler.

The shift to Linux happened around the same time, and few people would bother with anything else but GCC. It might have might made a difference if the Gelato Federation had arrived earlier, with more funding, and a mandate to conduct generic toolchain maintenance, in addition to Itanium-specific work. Kind of what Linaro does today. I think Gelato was way too late, and I don't recall it being particularly impactful (but it's been a long time ago, sorry).

The shift to Linux was a bit too late. By the time it happened, Itanium was lagging behind, with Intel resources relocated to match AMD’s 64-but x86 offensive. Maybe, with enough resources Intel and the FOSS community would be able to get the smart compilers an JIT optimisations that could have made EPIC a competitive architecture.

Sure it did. Some of my former colleagues built a top-five supercomputer using Itanium on Linux: https://www.pnnl.gov/news/release.aspx?id=487

Their complaints about that system really focused on the administration and provisioning issues. It ran code fine.