Inversion of Control allows a MicroApp to be less dependent on other MicroApps that it is using.
Let us compare two designs for a data store and content versioning. This is a strawman to illustrate the point, obviously there is a much richer set of solutions in Traditional or IOC style.
Traditional Design
The user interface makes a PUT request to /storage/content/12345 with the contents of updated content. The /storage/content MicroApp saves the new version to it's database. Next this /storage/content app calls PUT to /versioning/content/12345 to the versioning MicroApp. The PUT contains the old content value and the new content value.
IOCDesign
The user interface makes a PUT request to /storage/content/12345 with the contents of updated content and a 'afterSaving' url of /versioning/content/12345'. The /storage/content MicroApp saves the new version to it's database. Next this /storage/content app calls PUT to the afterSaving url. The PUT contains the old content value and the new content value.
Notice that when we write the IOC version of /storage/content, we are only concerned with saving the data to the database. The caller, which in this case is the user inteface, but could be any other MicroApp, can dynamically re-wire what happens after storage.
Explicit Control: We have to wire up components as an explicit step, perhaps in it's own MicroApp, instead of the "user interface".
Decoupling: We have decoupled /storage/content and /versioning/content, by use of DependencyInjection. Alternately this could have been done with a ServiceLocator.
Testing: We test /storage/content only for it's main use cases - store content properly, and make any callbacks which are part of a message.
Maintainability: There is much less code, complexity, and reasons to change this /storage/content MicroApp thanks to Inversion of Control.
Similarities: Plugin, Listeners, Callbacks