IA-64 was a dumpster fire. The halting problem is unsolvable. You can't schedule branch prediction absolutely. You have to have information about the current running program. Branch prediction, instruction re-ordering, and speculative execution are to hardware what a JIT is to software (roughly speaking).

Unfortunately, from a security perspective, moving those things to software doesn't make the vulnerability go away. You can have the same vulnerabilities in your software implementation.

From a performance perspective, we have no general solution to parallelizing a serial program. GPUs used to be VLIW. AMD switched from VLIW-5 to VLIW-4 because the average width was only ~3.5 (Nvidia had switched from VLIW to SIMD long before this). Today, Nvidia and AMD both use a MIMD threaded approach to execute on SIMD units.

Later-generation Itanium chips wound up including branch predictors and speculative execution. From what I understand, under the hood, they were normal RISC-style processors (like all the x86 micro-arch are today). Just ignore the VLIW and run one set at a time serially with the ILP hardware optimizing as it goes.

In today's programs, the programmer specifies data-level parallelism where possible (and if necessary, re-adjusts the code so the compiler heuristics recognize it as optimizable). The compiler then tries its best to detect the parallel data and use SIMD and organize instructions so that the parallelizable ones are closer together (so they fit in the CPU reorder buffer). When they hit the CPU, it examines the code as it runs to optimize speculative execution and uses the reorder buffer to make efficient use of its computation units (load, store, ALU, FPU, SIMD, etc). You move from explicit to implicit-ish (you know that putting similar instructions will optimize in all modern processors), but don't have the drawbacks of noop code bloat or having to compile different code when someone changes from VLIW-2 to VLIW-3 code.