It seems odd to distinguish between a plugin and a program running in a terminal pane. This seems to imply you must reimplement all such functionality as a new plugin, instead of just running your preferred tool, as usual, in a terminal window.
For example, they have implemented a file explorer as a plugin. But this means you can only use it when Zellij is available, and not as a standard tool on another system. This reduces flexibility and means you need different tools in different contexts.
I'd love to be corrected, but I can't think of any good reason why a special file explorer needs to exist, just to be coded to this plugin standard, instead of as a normal terminal program.
1. Ease of distribution - distributing a precompiled wasm blob is immensely easier than distributing an application
2. Sandboxing - both on the fs level and regarding special permissions, which brings us to
3. Stronger capabilities - you can use the terminal workspace around you by manipulating panes, tabs and other plugins, creating a workspace experience rather than a single app
4. More knowledge about the application - want to trigger when the user enters a certain folder? When a certain pane is focused? When certain text appears on screen?
5. Composability - integrate with other plugins to render a dashboard-like experience rather than a single app that a user needs to manually compose
While some of these are also achievable with native apps, I have found that if you give users (developers in this case) opinionated defaults that make integration easier - you'll get more people building more interesting things. Even if they technically can implement them all on their own.
Maybe you're focusing too closely on the specific example. It's interesting to me in the large for sure.
For one, since plugin permissions seem to be on the roadmap, users can expect to be able to write and run third-party code with a bit more confidence than if it were just another unix process.
Looking further down the line, imagine a pluggable web/native frontend for Zellij. At its most basic level of operation, it would still serve as a full terminal multiplexer, but it would also have the potential to do anything the containing runtime supports (render images, play video, render rich inputs/controls).
I wasn't imagining this before, but I kind of am now...
For example, they have implemented a file explorer as a plugin. But this means you can only use it when Zellij is available, and not as a standard tool on another system. This reduces flexibility and means you need different tools in different contexts.
I'd love to be corrected, but I can't think of any good reason why a special file explorer needs to exist, just to be coded to this plugin standard, instead of as a normal terminal program.