The title's a little odd, unless it was to grab attention. It's saying "Why [I use] 'not comments'", not asking "why not comments?" A "not comment" here is an explanation of why the programmer didn't choose the obvious approach. I agree: that's a very valuable thing to document for the next person.

For instance, you might write something like:

  # I used a bubble sort instead of a quick sort here because
  # the constraint above this guarantees there will never be
  # more than 5 items, so it's faster to use the naive
  # algorithm than to implement a more complex algorithm that
  # involves more branching.

or

  # Normally we'd do X, but that broke customer Y's use case
  # based on their interpretation of our API docs which we
  # had kind of messed up. So now we do Y because it works
  # under both interpretations, at least until we can get
  # them to upgrade.

Basically, tell your audience why you're not using the expected method. It's not because you didn't know about it, but because you do know and you've determined that it's not a good fit for this use case.