The Design of Everyday Things is instructive here. You don't design for the middle or the average. You design for the extreme edges. If you have a programming language that can be used both by absolute beginners who just want to learn enough programming to script their excel spreadsheet AND HFT traders who need to ring out every cycle of performance they can on every core they have at their disposal, then the middle will take care of itself.

On .NET's case the IL is never interpreted, it is only a portable executable format.

It is either AOT compiled to native code via NGEN, Mono AOT, MDIL or .NET Native.

Or JITed on file load before actually executing the code.

The only .NET toolchain, from Microsoft, that actually does interpret IL it is .NET Micro Framework.

The idea of using bytecodes as portable execution formats goes back to mainframes, of which IBM AS/400's TIMI is the best known example.

Didn't they use to have a IL interpreter, back in the days? Or was it already a compiler-maskerading-as-an-interpreter?

No, .NET never had an interpreter phase like the JVM.

Which actually can be configured to always JIT as well.

The majority of JVMs have a non-standard flag that allows to configure how the interpreter, JIT or if supported AOT compiler work together.

This is interesting to know, thanks.

It's not optimal for things like embedded, device drivers, high performance computing, etc. So I doubt everything will settle there. There will always be situations where C/Rust/Fortran are better choices.