I remember hearing this said about Lisp programming in the early 1980's. Specifically, there was a "tree-based" editor for InterLisp on the Xerox Lisp machines... I only ever met one person (hi Marty!) who even basically understood it.
I really hate the "we've never had one so we'll never have one" argument about anything, but I think in this case it may well be true, although the argument stems from the fact that a lot of people have tried to make "tree based" editors, but I've never heard of anyone making one that got any kind of traction.
Even the guy who could use the Xerox tree editor preferred emacs (on other machines).
The problem with tree editors has always been the lack of standardization, not any kind of conceptual or UI problem. Generally authors take one of two roots:
1) Provide a tree based editing UI layer on top of text files since text still rules. In my opinion this is almost like the worst of both worlds, though it can be successful. Paredit is probably the best example of this (and many lispers swear by it).
2) Create a Grand Integrated Vision of How to Fix Every Programming Problem Ever Created. This can make a nice demo, but of course never turns into a practical product any time soon.
Until we have a standardized tree or graph interchange format that is designed to satisfy the common denominator of the full range of languages, protocols, etc., as text does today, all structured editors will be fighting an uphill battle.
I really hate the "we've never had one so we'll never have one" argument about anything, but I think in this case it may well be true, although the argument stems from the fact that a lot of people have tried to make "tree based" editors, but I've never heard of anyone making one that got any kind of traction.
Even the guy who could use the Xerox tree editor preferred emacs (on other machines).