This article makes the same mistake as the last one. The inner save and restore of SP for the variable-length array is logically disconnected from the function epilogue, and not part of it. In a more complex function the disconnect would be more clear.
I suspect that it's because perilogue code, of functions or of inner block scopes, simply isn't subjected to optimization, other than the settings that control the existence of framepointers, smart callbacks, and whatnot, which are fairly fixed alterations to the boilerplate. People also probably don't want to risk peephole optimizing code that has been carefully arranged to exactly match calling conventions, possibly including expectations of specific instructions in specific places.
Ironically, the best optimization that isn't done to perilogues in the x86 architecture is to take out the PUSH/POP instructions and replace them with MOVs and LEAs, ironically making them more like perilogues on other ISAs.
* https://news.ycombinator.com/item?id=26317860