树允许按顺序遍历。
哈希表的最坏情况性能为O(N)（在一个桶中进行线性搜索），二叉搜索的复杂度为O(log N)。
注意：这需要树保持平衡，这就是为什么典型实现使用自平衡树（例如红黑树）的原因。
虽然这种退化情况比较少见，但不是不可能出现，而且它很大程度上取决于选择合适的哈希函数和实际数据的分布情况。
树的实现也很容易扩展到所需大小，而哈希表在填满一定比例（对于大多数实现来说是约70%的桶被填满）后性能开始下降。你需要重新对整个表进行哈希（对于实时应用程序来说是糟糕的），或者逐步移动到新的表格，这并不是一个简单的实现。
最终，STL 可能只选择了一种“基本”容器模板，即树，以避免额外的实现复杂性。
补充peterchen的答案，哈希结构虽然理论上插入和删除速度更快，但实际上取决于数据本身、选择的哈希函数以及数据量。
最佳和最差情况之间的性能差异很大，使它们不适用于通用结构。另一方面，二叉树更加可预测，独立于使用的数据量/类型，尽管在最佳情况下效率较低。
但是，如果请求的是22个字节呢？由于没有值为20的键，您必须迭代整个哈希映射以找到正确的键（30），这是一个O（n）操作。但是，如果您使用了一棵树，则“查找大于给定键的最小键”是一个O（log n）操作。
嗯，搜索树是有序的，哈希表则不是。
GetHashCode函数，使得每个对象都能存储在哈希表中。然而，这也给开发人员增加了额外的负担，即使他们不打算将该类用作哈希表，也需要实现语义正确的哈希函数。一种解决方案是从GetHashCode返回一个常量值，这在语义上是正确的，但如果该函数被用于哈希，效率就不太高。在 C++ 时代，人们仍然喜欢硬核学术方法来处理数据结构和算法，因此他们更喜欢占用更少内存并且最好和最坏情况都能够被很好理解的数据结构。
当 Ruby 出现时，为了脚本编程的目的，人们意识到他们更喜欢简单易懂而不是原始性能。由于哈希表允许使用顺序索引作为键来实现数组的语义，同时也可以使用自然键来实现字典的语义，因此它们被认为是更通用的数据结构。