This might make sense for I7, but not for Tads.
Of course. The point of that design was to take advantage of the work that had already been done for I7's action system, so authors could use the knowledge they already had. If TADS has a different way of doing it, great! Guncho just needs some way to pass messages in and out - what the game does with them is its own business.
This should be done in Tads code so that it works with all interpreters instead of introducing a special interpreter for this.
Well, there are advantages to hosting a game on Guncho, especially for "something more like a MUD": it gives you player profiles, access control, and collaborative editing; you can link your world to other games; you don't have to leave your computer running all the time, etc.
But there are also advantages just in having a common programming interface for the stuff that all multiplayer IF has to do, like directing messages to players or reacting when a player connects. Many of the library changes you'd need to make for multiplayer IF are the same no matter how the game is hosted, so if you're designing a multiplayer IF library, it'd be good to keep that in mind and build in some abstraction so your code and authors' knowledge can be reused.