You've rediscovered a couple of things...
"Binary tree" does not automatically mean "binary search tree".
The text-book form of a data structure isn't the end of the story. Data structures can be adapted and "augmented". Some augmented data structures are text-book examples in their own right - e.g. interval trees.
Adding extra summary data to each node is a fairly common trick with tree data structures. A favorite of mine is including subtree size information alongside key summaries. In that way, I have containers that can easily support subscripted access as well as key-based search. In my case, these are multiway trees with all data items in the leaf nodes (basically B+ trees). So the keys in the branch nodes are really just another form of summary - the first (or last) key in the subtree. With both subtree-sizes and discrete-typed keys, another sometimes-useful trick is being able to search in O(log n) time for the lowest key >= some minimum that isn't already present in the tree.
And obviously, it's just as valid to not have keys at all if you don't need them. A container that supports subscripting but not key-based search is, of course, an array or vector. A multiway tree version might be appropriate if you need a huge vector with frequent insertions/deletions at arbitrary positions, though it's a niche thing at best. A binary tree based vector might have some niche application too.
One example I have using subtree size summaries isn't really a data structure as it relies on underlying containers. It's used where the information is logically structured as a tree. In a BST, the data is logically structured as a sorted sequence - the end-user doesn't know or care that that's implemented via tree structures. This class is used where parent/child relationships are relevant to the application.
The underlying data is normally held in a similar way to how you'd build tree structures within a relational database - items have parent fields etc - though the library is decoupled from that by being a C++ policy-driven template. It works through a set of simple calls such as
Get_Next_Child and so on, which are usually trivial to implement.
I call the library an "XML tool", basically because it supports a view of the underlying tree that is similar to XML elements. You can traverse the whole tree, for example, and you will see begin "tags" and end "tags" for each node in the order you'd expect to see the tags in an XML file representing that tree. There's other traversal orders, such as "treeview" (preorder), and there's support for subscripting as well as simple traversal.
And there's support for summaries where every item gets a size (which can be zero, but not negative) and a running total is kept. I've used this e.g. for a tree-table control that I admittedly never finished. When an item is collapsed, it's total size summary for its descendants is forced to zero (with changes propogated up the tree) so that searches based on position within this view of the tree don't see those descendants. That makes it easy to find and iterate the currently visible items.
BTW - the unfinished GUI tree table control was never the most important application - it's just an easy one to visualise.