> That's just a basic constant fold optimization that can be statically handled

Incorrect. No static analysis can establish the constant in some of those cases if only because they are not provably constant. If the situation changes at runtime, those routines would need to be deoptimized and recompiled.

> It even has examples showing anything that would require runtime information (like mutable strings) don't get optimized.

The example does not show that "anything that would require runtime information don't get optimized" just that that case doesn't. I don't know Ruby, but I can imagine why guarding the constness of a mutable array may not be advisable.

> Incorrect. No static analysis can establish the constant in some of those cases if only because they are not provably constant.

Which one of those is not probably constant? They all are literally hardcoded constants?

The methods are not constant:

    def foo
      Array.send(:define_method, :sort) do; [100, 200]; end
    end

    puts eval([1, 2, 3].inspect).sort[1] * 2
    foo
    puts eval([1, 2, 3].inspect).sort[1] * 2

But, anyway, my points isn't about partial-evaluation of values specifically (although JITs can and do do that); instead of int and 2 you can consider a type with 4 billion subtypes. JITs do specializations that an AOT simply cannot possibly do (not without code explosion).

Now, as I wrote in the original comment, I'm definitely not saying that JIT compilation is "better" than AOT. I am saying that the "zero-cost abstraction" philosophy of C++/Rust and the "zero-cost use" philosophy of JITs are two extremes that are each perfectly suited to two very different software domains.