The first issue is the static versus dynamic scheduling problem. Static scheduling first requires a sufficiently smart compiler to output the correct static schedule. But you're also limited in your ability to parallelize based on what you can divine statically. Some operations have fundamentally dynamic execution times (memory operations, branches, and division operations are the most common of these), and if you guess wrong as to how long they're going to take, you're going to force the computer to do nothing where a dynamic scheduler could have slotted other work in instead
Additionally, you can only schedule work to be done in parallel within a relatively small scope, largely a basic block, and definitely on function boundaries. Functions like sin and cos boil down to polynomial evaluation, a chain of ~5 FMAs that have to be executed sequentially. Even if you have two FMA execution units, a static scheduler is forced to execute sin(x) * cos(y) serially, whereas a dynamic scheduler can usually get some overlap between the FMA chains.
A sufficiently smart compiler that can create the optimal static schedule for a VLIW chip can also emit the code so that the superscalar chip will dynamically choose the optimal schedule, so a VLIW chip ends up getting no better throughput than a regular superscalar chip, and if the stars align less well, will likely get worse throughput.
The other fundamental issue with VLIW is that it forces you to expose more of your microarchitectural details at the ISA level, which makes it harder to adjust those details (e.g., add more execution units) should you desire to in later chip iterations. Now Itanium does have a design which ameliorates this to a degree, but the cost of such a design is largely bringing back the transistor- and power-hungry aspects of the superscalar chip into your VLIW design, at which point you start asking how much you're really saving.