A lot of what we do is documentation: somebody asks a question about how to do something, we document that for them and for others as a lasting reference. We even give advice on how to do X in product Y, hopefully with supplementary information about why doing it the recommended way is 'the best solution'.
However, Documentation with a capital D (writing technical manuals on how to use websites, services or products) isn't what we should be doing -- it's a waste of our effort and (as the article you linked to pointed out) unlikely to be more attractive to users than official documentation.
As context, I'm currently leading the migration of the content of a crowd-sourced KnowledgeBase that has built up over nearly 18 years to a new technical platform, and we've taken the decision that we will NOT simply duplicate what's in the relevant Help File -- we will point to the Help file where we can't add value, and even include the online Help file in results of searching our KnowledgeBase. Where we can add value we will do so, by expanding an explanation or providing a video tutorial, suggesting use cases for particular features or steering users to adopt a way of working that long experience has shown will avoid problems down the line. We're lucky that we have a good relationship with the relevant software product's developers, which makes it easier for us to be a complementary resource rather than attempt to compete with their documentation. Here at GFH we won't have that luxury...
On the particular question that prompted this discussion, I'm not convinced that this is a good example of a "Documentation" question, even if we were to include them. It's addressing a transitory phenomenon with content that won't be relevant in a few months time (it evens highlights it's transience by including the date in the title), and as such I don't think it's a good question.
I think it would be much better rewritten as a question about whether and when such small matches are useful, and how to effectively use them.