I’m a bit puzzled how this helps prevent handcrafted binaries from exploiting CPU designs.
Well, if nothing else, the design of the Mill has a much smaller "attack surface". There's not nearly as much in the way of interesting activities going on behind the scenes as compared to a modern OoOE CPU. That logic is pushed out of the hardware and into the software development toolchain.
The Mill has many other aspects that improve the security story. All protection is based on memory address, for example. And pointers are not integers. There are reserved portions of the address space that programs are completely not allowed to touch.
The approach Mill Computing [0] is taking is to have the compiler toolchain handle all instruction scheduling for their new design. All instructions have a fixed, known latency (in terms of clocks). And the processor doesn't have much in the way of global state (like condition code registers and such). All metadata is stored with the data on the 'belt' (replacement for registers) itself, which is saved / restored upon context switch.
They are also years away from silicon it seems.
[0] https://millcomputing.com/docs/