Indeed. The incredibly clumsy way we choose to edit source code has baffled me since I was first acquainted with parinfer. Having to keep the source in the shape of a valid AST almost entirely manually is really annoying.
It's one of those things that, like visual programming, is absolutely and obviously The Right Thing™ until you try to implement it and use it.
That said, we have made progress in both areas, and maybe we will figure them out in the future.
That is to say, all things start out clumsy. And people that are good at it, no longer feel that it is clumsy. Which is why a lot of people that have been working with this for any time just don't think of this much.
If a tool is clumsy, we try to improve it, that has been the case since the first stone artifacts created a million years ago.
Do you think that the (sort of) tree-based affordances that most modern code editors do support, like autoindentation and brace pairing/enclosing, are silly too? What about some slightly more advanced features, like the AST-based "extend selection" and "move statement up/down" features in JetBrains IDEs?
Or do you think that the status quo just somehow happens to be exactly right and going any further would be silly?
That is, I am not disagreeing that it can be a little bit clunky. But, a lot of the power that experienced users have in reading code is specifically that they have built a bit of automaticity in reading it. That is, the clunky aspects of fixing it is something you pretty much have to do. You just build speed at automatically doing it rapidly.
So, the status quo is to use the helper functions that you want to use. But usually after you get the experience in the clunky phase.
I find it a nice middle ground between the craziness of vim and the slowness of traditional cursor usage.