我不确定的猜测是大多数库作者不想添加不必要的依赖项。因为字符串是每个Haskell发行版的一部分（它是语言标准的一部分！），如果你使用字符串并且不要求你的用户从hackage中挑选出Text发行版，它会更容易被采用。
这是一个“设计错误”，除非你能说服社区中的大多数人改变它，否则你只能忍受它。看看把Applicationative变成Monad的超类花了多长时间--一个相对较小但非常需要的变化--想象一下用Text替换所有String需要多长时间。
要回答您更具体的问题：我会使用String，除非您通过使用Text获得了明显的性能优势。错误消息通常是相当小的一次性事件，因此使用String应该不是大问题。
另一方面，如果你是那种意识形态纯粹主义者，为了理想主义而回避实用主义，那就选择文本。

• 我把设计错误放在引号中，因为字符串作为字符列表是一个整洁的属性，使它们易于推理，并与其他现有的列表操作函数集成。

如果您的API旨在处理大量面向字符的数据和/或各种编码，则您的API应使用Text。
如果您的API主要用于处理小的一次性字符串，那么使用内置的String类型就可以了。
对大量文本使用String会使使用您的API的应用程序占用更多内存。根据您的API的工作方式，将其与外部编码一起使用可能会使使用变得非常复杂。
字符串是相当昂贵的（至少5 N个字，其中N是字符串中的字符数）。一个字的位数与处理器体系结构的位数相同（例如，32位或64位）：http://blog.johantibell.com/2011/06/memory-footprints-of-some-common-data.html

在小型项目中使用[Char]至少有三个原因。

1. [Char]不依赖于任何晦涩难懂的人员，如外部指针、原始内存、原始数组等，这些人员在不同的平台上可能工作方式不同，甚至完全不可用
2. [Char]是haskell中的通用语言。在haskell中至少有三种“有效”的方法来处理unicode数据：utf8-bytestring、Data.Text.Text和Data.Vector.Unboxed.Vector Char，每一个都需要处理额外的包。
   1.通过使用[Char]，可以访问[]单子的所有功能，包括许多特定的函数（其他字符串包确实试图帮助它，但仍然如此）
   就我个人而言，我认为基于utf16的Data.Text是haskell社区中最有问题的决定之一，因为utf16结合了utf8和utf32编码的缺陷，而没有它们的任何优点。

我想知道Data.Text是否总是比Data.String更有效？
例如，“cons”对于字符串是O（1）而对于文本是O（n）。Append对于字符串是O（n）而对于严格文本是O（n+m）。同样，

let foo = "foo" ++ bigchunk
        bar = "bar" ++ bigchunk

对于字符串比对于严格文本更节省空间。
其他与效率无关的问题是模式匹配（清晰的代码）和懒惰（可以预见，字符串中的每个字符，懒惰文本中的实现依赖于某种程度）。
Text显然适用于静态字符序列和就地修改。对于其他形式的结构编辑，Data.String可能更有优势。

我不认为有一个单一的技术原因字符串保留。我可以看到几个原因，它去。
总的来说，我首先要指出的是，在文本/字符串的情况下，只有一个最好的解决方案：

• 弦乐演奏很糟糕，大家都同意这一点
• Text并不难用，所有常用在String上的函数都可以在Text上使用，加上一些在字符串上下文中更有用的函数（替换、填充、编码）
• 有两个解会产生不必要的复杂性，除非所有的基函数都是多态的。2证明：有SO questions on the subject of automatic conversions所以这是个问题。

所以一个解决方案比两个简单，而String的缺点最终会让它消失，越快越好！