This is not the case even in an interpreted language. You only need to build an AST once, at parse time. In JavaScript the AST is then compiled into byte code or machine code depending on the implementation.
In JS, if 1 developer and 9 users with a total of 10 separate browser instances all call the same function, the code will be parsed 10 times.
In Unison, the AST is generated by the developer, cached, and the 9 users can call it by hash (assuming they have access to that database where the AST lives) without reparsing the code.
The way I intend to use it is that users periodically assemble the codebases from all of the developers that they care about and merge them into a single codebase. This can be very latency tolerant (like, sneak-a-thumb-drive-across-the-border levels of latency tolerant) because it's not like you're waiting around for transport every time you want to do something, just every time you want to upgrade.
Then, when you decide to use the new version of something (the developer would communicate a new hash to you), you just start calling the new hash and now you're using the new software. If something goes wrong, you just go back to calling the old hash. No implicit trust (e.g. no need for SSL, DNS, package names), atomic upgrade/downgrades, no merge conflicts.