Isso é mais uma arte do que uma ciência. A Documentação do Mongo sobre Esquemas é uma boa referência, mas aqui estão algumas coisas a serem consideradas:

• 
  Coloque o máximo possível
  
  A alegria de um banco de dados de documentos é que ele elimina muitas associações. Seu primeiro instinto deve ser colocar o máximo possível em um único documento. Como os documentos do MongoDB têm estrutura e como você pode consultar com eficiência dentro dessa estrutura (isso significa que você pode pegar a parte do documento que você precisa, então o tamanho do documento não deve se preocupar muito), não há necessidade imediata de normalizar dados como você faria em SQL. Em particular, quaisquer dados que não sejam úteis além de seu documento pai devem fazer parte do mesmo documento.
  
• 
  Separe os dados que podem ser referenciados de vários lugares em sua própria coleção.
  
  Este não é tanto um problema de "espaço de armazenamento", mas sim um problema de "consistência de dados". Se muitos registros se referirem aos mesmos dados, é mais eficiente e menos propenso a erros atualizar um único registro e manter as referências a ele em outros lugares.
  
• 
  Considerações sobre o tamanho do documento
  
  O MongoDB impõe um limite de tamanho de 4 MB (16 MB com 1,8) em um único documento. Em um mundo de GB de dados, isso parece pequeno, mas também são 30 mil tweets ou 250 respostas típicas do Stack Overflow ou 20 fotos piscantes. Por outro lado, isso é muito mais informação do que se poderia querer apresentar de uma só vez em uma página da web típica. Primeiro, considere o que tornará suas consultas mais fáceis. Em muitos casos, a preocupação com os tamanhos dos documentos será uma otimização prematura.
  
• 
  Estruturas de dados complexas:
  
  O MongoDB pode armazenar estruturas de dados aninhadas profundas arbitrárias, mas não pode pesquisá-las com eficiência. Se seus dados formam uma árvore, floresta ou gráfico, você precisa efetivamente armazenar cada nó e suas bordas em um documento separado. (Observe que existem armazenamentos de dados projetados especificamente para esse tipo de dados que também devem ser considerados)
  
  Também foi apontado que é impossível retornar um subconjunto de elementos em um documento. Se você precisar selecionar alguns pedaços de cada documento, será mais fácil separá-los.
  
• 
  A consistência dos dados
  
  O MongoDB faz uma troca entre eficiência e consistência. A regra é que as alterações em um único documento são sempre atomic, enquanto as atualizações de vários documentos nunca devem ser consideradas atômicas. Também não há como "bloquear" um registro no servidor (você pode criar isso na lógica do cliente usando, por exemplo, um campo "bloqueio"). Ao projetar seu esquema, considere como você manterá seus dados consistentes. Geralmente, quanto mais você mantiver em um documento, melhor.
  

Para o que você está descrevendo, eu incorporaria os comentários e daria a cada comentário um campo id com um ObjectID. O ObjectID tem um timestamp embutido nele para que você possa usá-lo em vez de criá-lo, se quiser.