Cache Rules Everything Around Me, and bloated executables generally put more stress on the instruction cache, resulting in poorer performance.
Of course, this is just an approximate general rule, and extremely small binaries (and generally any "pointless" experimentation) like this are mainly interesting from a learning point of view (or for small embedded microcontrollers), e.g. understanding syscalls and program start-up, and, for the write-up you link, the ELF format. (Not everything has to be inherently useful for an actual task.)
To play the advocate, given that by default compilation produces a binary that includes over 2KB of Lovecraft quotes¹, this article at least serves to reassure people that you can produce a compact binary with Rust.
It may matter in some embedded applications (for which chipsets there is not even Rust compiler support yet) but the point is to show off how much low-level control you have over code-generation, and that no run-time is needed.
I'd care a lot more about performance characteristics than binary size
The key word here is I'd. The programming world is vast, and the range of hardware is likewise vast. So, so vast. Really huge. Pick a restriction you don't have to worry about; someone else out there does.
These exercises may lack practical value, except perhaps to the virus makers, but they do kind of prove there is no extraneous overhead required by the language.
So we already knew that about assembler, now we also know Rust can be twisted quite close to that too.
But honestly... does it really matter how small your executable is? I'd care a lot more about performance characteristics than binary size.
[1] http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...