I'd agree with his last sentence: "My guess, this was done more as an idiom of systems programming than as an optimization."
I was further stunned by the seeming naivety of the author's align_2() implementation, but then it does get the job done, eventually. My naive approach would've been roughly align_3(), but using integer math and modulus.
On the other hand, younger team members were recently stunned by code I did for translation of a binary protocol into more easily handled pieces using what I think of as typical idioms, so this article might get sent around Monday morning.
But you are right, this is indeed a very obvious line of code once you understand it. Thank you for your comments.
[1]Their words, heard within the past month.
E.g. modern C code tends to use "int" or "long" all over the place without considering if "short" or "char" is likely to be sufficient.
Similarly, you'll find bit fiddling wherever it is possible, including a tendency to use bit shift instead of multiply/divide even for constant factors where one might thing the compilers would optimize it to shifts (many early compilers didn't).
So it's not necessarily just an idiom of systems programming, as an idiom amongst "old school" C programmers in general. The extent to which it has carried through to more modern code, varies, though. I suspect systems programming has an overall higher ratio of "old school" C developers than application code does.
"Sufficient" is bit odd choice of word here. Word-sized types should be used unless there is a good reason not to. See nkurzs comment for a great example for this:
> The first 'movl' wipes out any bits greater than 32 if they are there. This is because x was defined as an int, and not a long.