You've been reading my mind.
When I took a compilers course, a few years ago, I discovered that if you take an AST and serialize it, with prefix notation instead of the usual infix notation, and use parentheses to delimit entire statements, you get Lisp. While I'd learned about Scheme (a dialect of Lisp) in my undergrad studies, I'd never really gained an appreciation for it. I definitely gained an appreciation for Lisp and its dialects, as a result of that course.
Problems with what you propose:
it's hard/slow to compose an AST in a graphical environment. After all, most of us can type faster than we can move a mouse. And yet, an emerging question is "how do you write program code with a tablet?" Typing on a tablet is slow/cumbersome, compared to a keyboard/laptop with a hardware keyboard. If you could create an AST by dragging and dropping components from a palette onto a canvas on a large, touchscreen device programming on a tablet could become a real thing.
few/none of our existing tools support this. We have decades of development wrapped up in creating increasingly-complex IDEs and increasingly-intelligent editors. We have all these tools for reformatting text, comparing text, searching text. Where are the tools which can do the equivalent of a regular expression search across a tree? Or a diff of two trees? All of these things are easily done with text. But they can only compare the words. Change a variable name, such that the words are different but the semantic meaning is the same, and those diff tools run into trouble. Such tools, developed to operate on ASTs instead of text, would allow you to get closer to comparing the semantic meaning. That would be a Good Thing.
while turning program source code into an AST is relatively well-understood (we have compilers and interpreters, don't we?), turning an AST into program code is not-so-well-understood. Multiplying two prime numbers to get a large, composite number is relatively straightforward but factoring a large, composite number back into primes is much more difficult; that's where we are with parsing vs decompiling ASTs. That's where the differences between languages becomes an issue. Even within a particular language, there are multiple ways to decompile an AST. Iterating through a collection of objects and getting some kind of result, for example. Use a for loop, iterating through an array? That would be compact and fast, but there are limitations. Use an Iterator of some kind, operating on a Collection? That Collection could be variable-sized, which adds flexibility at the (possible) expense of speed. Map/Reduce? More complex, but implicitly parallelizable. And that's just for Java, depending on your preferences.
In time, the development effort will be expended and we will be developing using touchscreens and ASTs. Typing will become less of a necessity. I see that as a logical progression from where we are, looking at how we use computers, today, That will solve #1.
We are already working with trees. Lisp is merely serialized ASTs. XML (and HTML, by extension) is just a serialized tree. To do searching, we already have a couple prototypes: XPath and CSS (for XML and HTML, respectively). When graphical tools are created that allow us to create CSS-style selectors and modifiers, we will have solved part of #2. When those selectors can be extended to support regexes, we'll be closer. Still looking for a good graphical diff tool for comparing two XML or HTML docs. As people develop those tools, #2 will be can be solved. People are already working on such things; they just aren't there, yet.
The only way I can see to be able to decompile those ASTs to programming language text would be something goal-seeking. If I'm modifying existing code, the goal might be achieved by an algorithm which makes my modified code as similar as possible to the starting code (minimal textual diff). If I'm writing code from scratch, the goal might be the smallest, tightest code (likely a for loop). Or it might be code which parallelizes as efficiently as possible (likely a map/reduce or something involving CSP). So, the same AST could result in significantly different code, even in the same language, based on how the goals were set. Developing such a system would solve #3. It would be computationally complex, meaning we'd probably need some kind of client-server arrangement, allowing your handheld tablet to offload a lot of heavy lifting to some cloud-based server.