The article has a great example of this in the int_to_str code. While it's far from optimal code (e.g. the "mov rbx, 10" should really be outside of the loop, the "add rdx, 0x0" is useless, etc.), it's using the stack in a way that a compiler would probably never do, and something that likely isn't possible to express at all in a HLL. The C version would involve at least allocating an array with some pointers into it to act as a stack.
It's in these approaches - fully exploiting the features of the machine - where human-written Asm really shines. In some ways, the compiler "has its hands tied" when it comes to generating code, since it is limited to generating code that represents ideas in the corresponding HLL; it can make use of extensive knowledge of microarchitecture to schedule instructions/uops, sophisticated algorithms for register allocation and instruction selection, and generate code that is faster on a particular model of CPU than if it did not, but this falls short of the human who realises that neither a separately allocated array, nor such instructions to manipulate it, are actually needed.
The human can apply even more extreme optimisation making use of microarchitectural details if she so chooses; but the fact is that even without this, the code is probably already better than what a compiler can do. In practice, for general-purpose-code (i.e. excluding additional features) most models of x86 are all quite similar since the P6, and Intel has been doing a great job at making existing code faster with each new generation, so there is little need to go to that extreme; the optimal sequence of instructions for one model is often the same or close to optimal for the next one. (The odd ones out are the P4, and possibly some of the early Atoms.)
Another item that appeared on HN a while ago illustrates this "think outside the HLL/compiler" idea too: http://davidad.github.io/blog/2014/02/25/overkilling-the-8-q... ( https://news.ycombinator.com/item?id=7301481 )