One application domain where binary trees are better, or more easily adjustable than certain alternatives, are persistent data structures (which are often used in (purely) functional programming).
A persistent data structure is a data structure that preserves the previous version of itself when it is modified. (Data structures that do not have this property are called ephemeral.) One benefit of this kind of data structure is that it allows sharing of parts of the data structure - since the structure itself is guaranteed not to change, it is safe to share it freely between other data structures and even threads without worrying about it changing. Another subjective benefit is that these data structures are easier to reason about.
Conceptually, you could have an immutable data type that is a list of numbers, e.g., $L_1 = \{3,4,5\}$. Then you could introduce a new value that adds two numbers to the front of this list: $L_2 = cons(1,cons(2,L_1)) = \{1,2,3,4,5\}$. What happened to $L_1$? Nothing - $L_1 = \{3,4,5\}$, still. Did $L_2$ copy those three elements and put it into its own list, then? Ideally not - the values in list $L_1$ belongs to $L_2$, also:
$
\overbrace{
1, 2,
\underbrace{3,4,5}_{L_1}
}^{L_2}
$
There are data structures that are more well-suited for implementing persistent lists like the one above. In the same vein, binary trees are more well-suited for implementing persistent data structures with certain properties, than other data structures or strategies. And the structural sharing shown in the example with the two lists carry over to binary trees - you can imagine that several versions of a tree can share sub-trees that they have in common.
Like I said, some data structures are easier to amend to be persistent. You mention hash table, which is typically (if not even necessarily) an ephemeral data structure. It seems less obvious how one can adjust a common implementation strategy for a hash table to be persistent. Consider that a hash table is often implemented with an array (specifically, arrays that are implemented as a continuous part of memory). Arrays are nice since they provide random access to elements, which is an important property since you ideally want to have $O(1)$ average access to elements in the hash table. But arrays aren't that nice when it comes to building persistent data structures. The gist of it is that, while you can make an immutable array data type, by the nature of arrays, you risk having to do a lot of copying - If the aforementioned List type was implemented with arrays, you would risk having to create a whole new array with five elements, instead of sharing part of it. And what if you want to modify something in the middle of the array? The most obvious - and seemingly unavoidable - answer is, again, copying.
Persistent data structures do not avoid having to do copying, in general. But certain data structures make copying less frequent. This is a desirable property when you demand that a data structure has to be immutable.