The endgoal is probably to allow neater refactoring opportunities and raise the level of efficiency by standardising on an easier-to-parse-into-AST-like-structure syntax, enabling generic tools to be built that will deal with such structures directly.
While I sense that there is something smart that could be done in that area, there are already plenty of de facto standardized languages for structured data (most notably XML), and already a bunch of real world programming languages that work.
So I think it'd be easier to grasp their goals if they started off of an existing language ecosystem (that language spec is the definition for their AST parser), and attempted to build the tools they want: this would have more quickly formalized what's missing in the source code format for it to remain human editable, but at the same time easier and richer to parse.
Again, it's all a bit vague since you can build a development environment based on text files where you are not seeing all of that generated text at all times (if ever).
As the goal seems to be to find improvements to the process of program development while being unconstrained by complexity of (re)parsing text files repeatedly, I would have started with trying to add those improvements and ignoring the slowness/cost of parsing (or simply used an existing language that's cheap to parse, like Lisp).