An advantage of WASI is that it mostly works on non-WASI runtimes too, as it can be compiled to one or more normal modules (with the multi memory feature).

So a possible reason is that maybe they are not interested in offering general interfaces but just a single python specific one.

In this case they could have likely used wasi for that too but I can see how it could have been seen as an overhead

> For the use cases in this article, the best option is wasmtime-py.

They seem to have gone with a WASI runtime. Though to me, the caveats after it, and throughout the article, make it seem like Wasm is more difficult to deal with than PyO3's excellent ecosystem rather than the opposite.