In practice, it rarely happens even in micro-benchmarks like these. Though pointer aliasing rules are a special pain point. If you're sure you know what you're doing, restrict exists as a band-aid over this. Yay archaic language baggage!
LLVM's optimizer also doesn't help, as the post mentions—I have real-world code that runs at 1/3rd the speed just from compiling with clang instead of gcc. I love LLVM for what it's let people build on top of it, but it isn't remotely state-of-the-art in this department.
I used to believe this, but I think the same level of theory that says a JIT can be sufficiently smart enough to figure everything out means that a compiler can be sufficiently smart enough to figure everything out as well. This is one of those areas that theory and practice are so far apart that theory should be accompanied with a context of "some day, in the future, if we're lucky..."
What we've seen in reality is that as JIT engines get better, compilers also get better, and retain their lead.
In theory your could still benefit from JIT if, say, you have a Java application that's half written in XML config files and always heavily customized for each deployment. But probably that application also needs 8 modern cores and 16GB RAM to start for reasons that aren't even Java's fault.
But I try not to write code like that.
If the compiler is allowed to embed a JIT or other runtime system, then all bets are off.