まず大前提として、その記事はFirebase Realtime Databaseですね。それとFirestoreは似て非なるもの(特にサブコレクション概念の有無が大きい)であって、最適なデータの持ち方は異なります。

users部分のpostsを{key: true}みたいな形で持たせればデータ量も小さく収まる

とはいえ、これはFirestoreでもありですね。ただ、そのデータの持ち方だと1ドキュメントごとにpostsからデータ読み取りの必要があって(クライアントジョイン)、一長一短です。

また、サブコレクションではなくusersドキュメントに含めるとpostsの量が増えるとusersドキュメントが肥大化する問題もあります。

どちらが良いかは一概に言えず、そのアプリの細かい要件にトータルとして適したデータ構造をしっかり選定するのが大事です。僕の記事も「このデータ構造がベスト」という主張などでは決してなく、色々取りうるデータ構造を考えながらしっくり来るものを選定していく形としているつもりです。

また頭で考えるだけではなく実際に触って掴めるところも多いと感じていて、実際に色々なデータ構造のパターンを組んで試してみることをおすすめします。