These days, the first answer to any “how can languages retain performance while X” question is optimising JITs, rather than needing necessarily to be part of the language or library design. These will automatically perform type specialisation, inlining, loop fusion, and so on, using the information available at run time (including about the concrete data being processed) at performance-critical points in the program.
Bespoke JIT implementations aren’t as complex to build today as in the past, with tools like Truffle/Graal or PyPy allowing you to build an interpreter and any language-specific optimisation steps, then get access to standard optimisations along with that, or the implementation can simply target an existing optimising VM’s bytecode.
Traditional static optimisations are also very effective in these sequential-loop cases and avoid the JIT overhead, but don’t have the ability to respond to information unknown at compile time. Inlining lambdas and higher-order functions, performing loop fusion and unrolling, array bounds optimisation, peephole optimisation of the revealed instruction sequences, and other standard compiler optimisation techniques also produce good performance for exactly this type of code. While they can be implemented directly, compilers targeting existing compiler backends like LLVM are able to take advantage of their optimisations “for free” as well.
Only if these standard optimisations aren’t effective, or for targets where JIT compilation is not possible or suitable, is a language design change necessary for good performance. Systems languages (like Rust) or those targeting embedded systems can be instances of those. However, other languages could have conventional usage patterns that weren’t friendly to these as well (particularly JIT compilation).
There is another side of performance where enabling parallelism may be a more valuable benefit, and one that that API or language design can assist. Automatic parallelisation of sequential code is notoriously hard and an active research topic, but is likely to require specific language design choices in practice, like purity or isolation guarantees.