Other commenters have given most of the reasons already, but since you asked specifically for the author, I'll chime in as well.

The fact that Roto gets compiled at the runtime of the Rust application is very important. That means we can ship a binary and still allow scripting.

We also believe that Rust is too complicated for our use case in some respects, we're trying to make something simpler. Our target audience for Rotonda is not people who necessarily know Rust. We can never be as simple as Lua because of the static typing, but we're trying our best.

And finally, we don't have to ship the entire Rust toolchain with our application. Roto is fully embedded into the binary with no external libraries needed and that's quite nice in practice.

I'm author of a rust based task manager (not (yet) FLOSS, unfortunately), where we needed "pluggable task sources" (jira, github, trello, etc).

In our setup, the "sources" are more like configuration. Whereas the core, the business logic, is more like code.

Typically, one would configure with e.g. YAML. As we can see in many projects, that have a DSL, in yaml (k9s, GitHub actions, ansible, etc). But, rather than inventing another DSL in yaml, we realized we do need some logic, something very poorly expressed in yaml. And we went for Lua.

Long story to say: if your config typically has some logic in it, it makes sense to go for an embedded scripting language to provide it, rather than building it into the core domain, or to invent yet-another-yaml-amalgation (yayamla?)

Same reason why several projects have integrated Lua to their runtime over the past 30 years. Extensibility and hot reloading.

Hot-reloading. You can edit your logic without rebuilding and restarting the host application; this cuts your iteration time from minutes to seconds, especially if the application is in a state that would need to be recreated.