直交するコンセプトを明示できるのがタグのいいところ？

「必ずタグを付ける」理由として、「その情報が取り出せるという安心感」を得るためだということですが、情報へのアクセスを保つためには、タグだけではなくて、つながりを作ってネットワークを維持する方法もあります。例えば、EBtはそのように活用されていますよね？
Piggydb でも EBt でも、つながりが最も重要と思います。
ただ、例えば A→B→C→D→E→F というようなつながりがあり、A・C・E のグループと B・D・F というグループについて、先のつながりとは直交したコンセプトがあれば、A→C, A→E, C→E というようなつながりを個別に作っていくよりは、A・C・E について X、B・D・F について Y というようなタグを立てた方が作業が簡便で、かつ、それぞれのグループの意味付けをタグ名称で明確に意識できるところがいいと思います。グルーピングし直しのコストが低いところも魅力です。もちろん、例えば A→E に強い関連性があれば、それはつながりをつければいいのですが。
EBt ではタグに相当する機能はないので、上記の例であれば、まず A⇔B⇔C⇔D⇔E⇔F という関係（EBt は双方向つながりなので）で 5 つのメモを作って、X、Y というノード（タイトルだけの空メモ）を別に作り、X には A・C・E それぞれと、Y には B・D・F それぞれとのつながりを作ります。
Piggydb でも、主にドキュメントビューでの利用を想定して、タイトルだけのフラグメントを作り、それに対して複数のフラグメントを並べていく場合がありますよね。あれと同じでしょうか。ドキュメントビューで使わないならわざわざそうしなくてもタグをつけた方がスマートなような気がします。

—

まさしくその通りです！フラグメントの構造とは直交するコンセプトにタグを利用する、言い換えると、複数の構造（ネットワーク、あるいはツリー）を横断するものですね。横断しているということを示したいがためにタグという要素を別に用意している、と言ってもいいかもしれません。
EBtでも、タグとして機能しているX、Yを他のメモと区別できるように「タグ」というタイトルのメモで修飾すれば、同じようなことができます。Piggydbで言えば、一階層のタグセットとして認識できます。このように、EBtにおいて、タグとして機能しているメモを区別する必要があるのかないのか、あるとすれば何故なのかを考えれば、タグという概念の必要性について、ヒントを得られるのではないでしょうか。
そのメモ（あるいはフラグメント）を選択すれば、そこからつながる別のメモが見える、という機能に限って言えば、つながりはタグの代用になるわけですが、Piggydbにおいては、その他の機能で以下のような差別化を行っています。
つながりにページングが無いのは、それほど大きな数のつながりが作成されることを意図していないということですし、タグページにページングがあるのは、大量のデータを修飾の対象とすることを意図しているからです。 つながりの順序は以前話題になりましたけども（#208）、順序は空間上の配置を意味しますから、これはつながりが基本的には構造的な関係を表すということです。
ちょっと堅い言葉で言いますと、タグの修飾は「概念的包含関係」を表し、つながりは「構造的包含関係」を表しています。この二つの区別には常に混乱が付きまといます。
タイヤは自動車の下位概念ではない。タイヤは自動車の部品である。自動車事故は自動車の下位概念ではない。自動車事故は自動車に関連する概念ではある。

— → ...

EBtでも、タグとして機能しているX、Yを他のメモと区別できるように「タグ」というタイトルのメモで修飾すれば、同じようなことができます。Piggydbで言えば、一階層のタグセットとして認識できます。このように、EBtにおいて、タグとして機能しているメモを区別する必要があるのかないのか、あるとすれば何故なのかを考えれば、タグという概念の必要性について、ヒントを得られるのではないでしょうか。
EBt 歴もまだそんなに長くない私がいうのが適当かどうか分かりませんが…。
EBt で「タグとして機能しているメモを区別する使い方」のユーザはいらっしゃるかもしれませんが、「タグとして機能しているメモを区別する必要」はないように思います。
私の例で言えば、
  1. もともとのつながりよりも、後で（Piggydb でいえばタグ的に）つけたつながりの方に意識のフォーカスが移ることが多々ある。
  2. 元々はノード（空メモ、Piggydb でいえばタグ的）だったものにメモコンテンツを加筆する場合があり、Piggydb でいえばフラグメント化することがある。
という状況ですので、こっちが「概念的包含関係」でそっちが「構造的包含関係」、というような意識をすることは EBt を使う限りに置いては全くありません。
要は私のいい加減な使い方に、EBt の自由度が高いことがずばりマッチングしているという感じですね。