If you enjoyed that piece of code you might also enjoy the C code linked here: http://blog.jgc.org/2008/02/tonight-im-going-to-write-myself...
Perhaps there should be a 'beautiful code' blog as a sort of counterpart to the Daily WTF. I could reuse the domain usethesource.com.
Update: An there it is UseTheSource (http://news.usethesource.com/news). Submit examples of beautiful or interesting code.
Personally I like the code to be as self documenting as possible about the "what", the check ins to be as explicit as possibly about the "why" (and "who" and "when") and documentation for architectural information ("where").
As you mentioned, there are different places for documentation: inline, commit comments, change tracking system, project/release planning documents, and overall system architecture documents. These all serve different purposes, describe different aspects, and typically have different audiences. They all have different levels of detail too. The code itself is the most detailed documentation, because it describes what the software actually does when it runs, and should be as readable as possible. The inline comments supplement that, because the code describes "what" but not "why". You mention that check ins should describe "why", but they give the why for the overall change, not for each block of code. Inline comments give the why for each block of code.