I think what we need is "Elm error messages" (http://elm-lang.org/blog/compiler-errors-for-humans) for AST editors. Take paredit for example. If you're trying to delete a closing parenthesis, instead of refusing to do so and silently fail, display a tooltip that explains why such action is disallowed, and a list of (heck, hard-coded even, like some Elm errors) likely actions the user's trying to take. Deleting the list? Deleting just a token? Show the keybindings. Or even automatically pick the most likely action after a second invalid delete attempt.
I actually believe the constraints imposed by structural editing can be very beneficial (again, see paredit which helps your program stay syntactically valid). But constraints are good when they're visible. You can exhaustively check what's there. Constraints are frustrating when they're invisible and you repeatedly accidentally stumble against them.
(Ideally you'd also provide a free-form mode where you can edit things as plain text. But from personal experience I'd just go back to this instead of learning the AST editing keybindings.)