IIRC, wasn't part of the issue that compile-time instruction scheduling was a poor match with speculative execution and/or hardware-based branch prediction?

I.e., the compiler had no access to information that's only revealed at runtime?

Yes, absolutely. Itanium was designed with the expectation that memory speed/latency would keep pace with CPUs - it didn't.

Could it have been a good target for e.g. Java JIT? It would be able to instrument the code at times, and then generate more optimal code for it?

I think you may be right. It's hard for me to find then-contemporary benchmarks from 20 years ago, but this snarky Register article mentions it indirectly:

https://www.theregister.com/2004/01/27/have_a_reality_check_...

SPECjbb2000 (an important enterprise server benchmark): Itanic holds a slim (under 3%) lead over AMD64 at the 4-processor node size and another slim (under 4%) lead over POWER4+ at the 32-processor node size - hardly 'destroying' the competition, once again.

It was slightly faster than contemporary high-performance processors on Java. It was also really good at floating point performance. It was also significantly more expensive than AMD64 for server applications if you could scale your servers horizontally instead of vertically.