I have different scenarios in mind. For example:
One could be a widget that works just like a Meteor app, based on data from its own back end, but that can get queried based on the context on the host app (where the widget is installed). So depending on the context of the host app it will produce a different response. A simple example could be a weather widget, which shows the weather and other geo related information based on what the user is browsing on the host app (not just the geolocation of the user). This, of course can be done via iFrames exchanging data between the host app and the iFrame (the Meteor widget) using cross-domain messaging with postMessage. However, for more complex scenarios that could be complicated.
Another case could be to use the Meteor app to handle the Single Sign On (SSO) for a couple of applications that already exists. For example, a community site and a learning portal for the same community that were built with other tools. Both are independent sites, but they serve the same user base. In this case it would be nice to have a SSO solution that can handle the users on both sites 9which are the same), without having to create two different accounts and profiles. In this case the Meteor app is a service that handles the SSO and manages all the profile data. This can be extended to track what the users are doing and provide an engine for, say, contextual recommendations, or game mechanics (keeping a leader-board of users based on activities on both sites, etc.). In this case, it could allow developers to create their own services similar to Gigya, or hull.io and others. So it could have a set of (connected) widgets (front-end) that can be included in the host app(s) in different places. The SSO component in the header nav (in both sites) , the leader-board in some pages (in both sites) and some back-end communication (two-way).