The most obvious use for this is to distribute an application with a scripting interface.
Users can write simple scripts which change behaviour, or react to events, without needing to learn a toy-language, or even necessarily have a compiler setup.
There are some circumstances where an interpreter is useful: For example, it should be possible to make better golang repls with an interpreter than with a binary.
In a "scripting" scenario, you can load some golang code at runtime without needing to bring the full golang compiler toolchain along, which keeps the nice "single binary" deploys of golang. It may be possible to sandbox scripts as well (though I haven't looked into how that could work with this implementation), which could reduce the risk of running scripts (less likely to shoot yourself in the foot. Probably not a security boundary -just look at how much work goes into safe JS in browsers to have that).
I'm working on an approach for Golang sandboxing which works through whitelisting imports, and munging all references, casting operations, and function calls, which lets one whitelist those as well. I would disallow all io and network access.
Could you not just hijack the system calls/c runtime? Then you can still do "safe" I/O without a specific API (Or are you rewriting the stdlib on top of the API? I've never actually used go so I don't really know anything about how it does or doesn't work usually)
Users can write simple scripts which change behaviour, or react to events, without needing to learn a toy-language, or even necessarily have a compiler setup.