The author's examples -- proofs and ASTs -- provide a hint at the reason.
If you need a tree, it's most likely that you want some custom operations on that tree (e.g. parsing text into the tree, pretty-printing the tree, traversing the tree in various ways, etc.)
At some point, the tree is just a data structure and what you're interested in are full-blown, non-trivial algorithms/programs for fairly domain-specific tasks. In these cases, a library (or even custom implementation) for a general purpose programming language is more useful than a tool (a la Excel or vim).
Viewed in this light, it's not unsurprising that we have many domain-specific tools for manipulating trees. Most of the proof assistants have a GUI based on Gentzen-style sequents.
LaTeX has styles for type setting proofs which look like the ASCII ones in the article.
Tools for generating parsers often have tree-based UI's.
You're right that most of the time we need non-trivial algorithms or visualizations for trees for it to be useful. If I ignored that it would be like wishing for a "general binary editor" because it would be so "powerful" and all data can be represented as binary.
I think, though, that there's enough common ground between the various domain-specific tree editors that some kind of useful intersection exists. Then the domain-specific tree editors would simply be plugins.
Perhaps the "killer app" is an extensible GUI framework with some sensible defaults already implemented (e.g. those mimicking some of the design dimensions explored by the software mentioned in other posts), combined with a scripting language and/or a suite of good libraries/apis for popular languages.
If you need a tree, it's most likely that you want some custom operations on that tree (e.g. parsing text into the tree, pretty-printing the tree, traversing the tree in various ways, etc.)
At some point, the tree is just a data structure and what you're interested in are full-blown, non-trivial algorithms/programs for fairly domain-specific tasks. In these cases, a library (or even custom implementation) for a general purpose programming language is more useful than a tool (a la Excel or vim).
Viewed in this light, it's not unsurprising that we have many domain-specific tools for manipulating trees. Most of the proof assistants have a GUI based on Gentzen-style sequents.
LaTeX has styles for type setting proofs which look like the ASCII ones in the article.
Tools for generating parsers often have tree-based UI's.
And so on.