说一些我现在能想到的。
最重要的是，TAGS 格式本身信息不是很丰富，基本上就只有名字和位置信息。tags 格式更加丰富一些，你看我的截图里那些符号都标明了种类（也就是说一个符号是 macro、function 还是别的什么）和类型。
基于这些信息，Citre 可以实现更准确的过滤和排序。一个很实用的东西是对非全局的符号，ctags 会标明它的 scope 是 file。Citre 在找定义或补全时会排除具有 file scope，且不在当前文件中的符号。这样可以排除大量不需要的结果。
另外，注意到我自动补全的截图中，由于当前符号在一个 . 的后面，Citre 推测你需要一个结构体成员，因此补全出来的结果中 member 种类是放在其他结果前面的。虽然基于 ctags 的工具做不到 lsp 那么智能，但我们可以提供类似这样的贴心小规则。利用 TAGS 文件是不可能做到这一点的。
总而言之，更丰富的信息可以帮我们更好地理解代码。试想我们要做这样一件事情：我需要某个库里面的一个函数，我不知道它叫什么，但它的功能是插值，所以里面应该有 interpolate 之类的单词。。。我们可以把这些条件扔给 readtags，让它帮我们找我们想要的东西。或许在将来 Citre 会提供一个交互式工具让你做这件事情，而利用 TAGS 文件的话是绝无可能的。
另外，TAGS 格式是按照文件和行号顺序排序的，而 tags 是按照名字的字母顺序排序的，因此 readtags 可以做二分搜索，使得在大工程中补全和找定义也相当快。company-etags 应该做不到这一点。
Edit: 还有一点是 TAGS 文件一般是整个加载到一个 buffer 里使用的，对巨型工程来说不现实。Citre 不需要做这样的事情。