This architecture has the advantage of creating a federated architecture, with only one half of the client-server stack to worry about. Almost any existing server can serve the required json to the federation, and new servers can be written in a few lines of code. All we need to worry about is the development of the wiki-client.
The wiki-client depends on new plugins to be created for each new service. There is a great deal of simplicity and power in this approach. However being able to integrate existing software stacks into the federation requires a rewrite. This is not such a draw back as it could be due to the extensive nature of the npm ecosystem.
The current browser-based federation has the merit of being pragmatic, modern, simple and light-weight. This approach should not be compromised, and independence of the browser based wiki-client to consume json from whichever source it like maintained.
However, this independence, does not and should not preclude an equal and equivalent form of federation taking place in terms of those services that provide json to the wiki-client. In tis way we can envisage doubling the growth-rate of useful services provided to the federation, without either system compromising the independence of the other.
The federation, so conceived is essentially a JSON Pipeline of actors that consume, process and send json data structures to each other. In this word the browser is the canonical display device, but not necessarily the only one.