1. Better memory locality by knowing what you load and when, exactly.

2. The ability to "cheat" on calling conventions.

3. The ability for techniques like threaded code, and in general, better cache-awareness.

4. Less mov's.

5. Guaranteeing no spilling in important loops.

6. Compilers don't do well with flags registers and you can't read/write them in high level languages. You're hoping your `if (result < a) { carry = 1; }` becomes a direct flag test. Especially important in bignum, you can't really utilise adcx/adox directly from high-level code.

7. Hot/cold layout without PGO. Yes PGO is good but sometimes you know better and PGO isn't very suitable for "configurable" code.

8. Computed goto. See https://github.com/python/cpython/issues/128563 , who doesn't like 10% free performance?

9. Exploiting uninitialised memory for classic party tricks like not initialising a buffer fully (let's say you have a library function with a return buffer. You don't want dynamic allocations for some reason. You can simulate this with a pointer return into a let's say a static 4KB buffer and a count return, you only initialise it until the count. Caller has the responsibility not to overread.)

Any “Multimedia Extensions” or streaming or whatever beyond what’s available past a 486.

Rust has autovectorization, but a developer knows their algorithms best.

Also AES-NI vs software is no contest.

When people talk about out coding ‘to the metal’ you have to consider what ‘the metal’ provides

usually with Rust impactful savings come from writing the Rust differently, not from doing hand-written assembly instead.

See stuff like https://davidlattimore.github.io/posts/2025/09/02/rustforge-...

This doesn't mean Rust is near perfect, it's just that your first move should be "how do I make the Rust better" and not "I need to drop into asm."

Entirely situation and application specific. Just like with every other language.