One realistic use case that comes to mind for WebAssembly modules outside the browser is extension plugins for tools like Maya, 3DSMax or Photoshop. For such cases it's usually ok to provide a restricted set of APIs, but you gain binary compatibility across platforms and performance that's much better than (for instance) Python or Lua scripting.
On the bright side - since this is a brand new thing built from bottom up, we're not limited by past API design choices.
In particular, I hope that this time we can get a standardized ABI that goes well above what C (the current de facto standard) had to offer. Language evolution went far beyond where things were back in 1980s, and the set of common features across various languages has also increased substantially - and that should be reflected in the ABI.
Speaking of which: https://github.com/Microsoft/xlang
Consider that browser standards include an enormous amount of functionality and new web API's are getting added all the time, and yet, many people claim that web apps can't compete with native apps on phones or desktop. Also, even if you just pick one of these, there have been many attempts to come up with a portable way to write apps for both iOS and Android, and it's getting better (see Flutter for example), but it's still a lot of work for the implementers.
Docker got around this by standardizing on Linux (including the filesystem), but the client side is much harder.
So I suspect that for a "universal" file format based on WebAssembly to get anywhere, it will have to succeed in some niche not served well by web browsers, Docker, or Unity.
WebAssembly itself is useful in the way a fast interpreter for a scripting language is useful - as an embedded component of some larger runtime. Its potential customers are teams that would otherwise need a scripting language and choose WebAssembly instead.