I think the Industry rather likes heavily constrained languages. There's a sense in which that's the point of a language - it's an abstraction that cannot be breached, which limits what you can ask the underlying machine to do.

C++ won't let you define new types at runtime, but the advantage there is you know that the rest of your C++ codebase won't be doing that. It won't let you reflect on runtime data, but that means various changes you make to your program are undetectable outside of bounds (class or translation unit, sometimes shared library).

Forth or assembly will let you do whatever the hardware is game for because either can emit raw bytes and then interpret them as machine code. The cost is you have, at best, conventions about what the rest of the codebase is doing.

If you push too hard towards high performance in C++ the language lets you down. Aliasing rules mean data must be always atomic or never, and can't sometimes be an array of simd values. Or fno-strict-aliasing which costs you elsewhere. No control over calling conventions, instruction selection, register allocation or scheduling. On the bright side you can usually force partial evaluation well enough with template instantiations, but you can't have the inverse where you explicitly fold equal machine code implementations on different types. Plus trivial stuff like the embarrassment of unique_ptr imposing overhead if you pass it to a function. So C++ will get you within N% of optimal, most of the time, and that's usually good enough.