I don't think these limitations are ones that really impact hardware all that much. It wouldn't be impossible to create hardware with the concept of "infinite registers" that ultimately gets optimized away. (see: Mill CPU)
The bigger issue (IMO) is that the IR for compilers tends to evolve rapidly while hardware is stuck in the mud. Moving the problem of finalizing the IR into the hardware will effectively make it so you'd change your compiler to emit IR that targets old IR.
This is why, for example, x86 will get a new instruction which will effectively go unused for 5 to 10 years (except in extreme cases where the performance gains are worth the cost of writing code to detect and use those new instructions... For example, FMA). Those who compile code want it to be able to run most anywhere in not so surprising fashions, so they'll target the LCD.
Now, imagine someone was building a JVM bytecode chip today. The JVM is on a 6 month release schedule. That's incredibly hard for a hardware manufacturer to want to keep updating their chips at that rate. Further, even if they targeted "LTS" versions, they've moved that to a 2 year cycle. Again, hard to really expect customers to want a new JVM chip every 2 years.
The likes of GCC and LLVM IR change and expand just as rapidly (if not moreso) than than JVM.
There is the option of something like FPGA or programmable hardware leaking into more places, but IMO, the HDLs and their tools simply suck too bad to expect FPGA on an ASIC to really take off. We need a first mover here and after that happens, I expect at least 5 to 10 years before the tools get to a level that doesn't completely suck. Even then, while access to GPGPUs is now pretty much universal, GPGPU programming still feels like it is in the stone ages. Despite being a thing for over 10 years. So how can we expect HDLs to evolve at a faster pace?