BizTalk offers a great number of capabilities, not the least of which are persisted durable messaging, Orchestrations, pub/sub messaging. What the MSE offers is a way to version the capabilities you may expose from BizTalk. In addition, since
the MSE doesn't persist messages through the MessageBox like BizTalk does, it avoids that extra latency.
The MSE in conjunction with BizTalk is definitely a "better-together" story where the MSE acts as the primary intermediary. For example, operations that require orchestration and/or long running workflows, let the MSE route the message
to a BizTalk Orchestration. However, if the message does not require this, avoid the overhead of BizTalk and let MSE route the message directly to the service implementation. The MSE can shield consumers from changes to orchestrations.
Another perspective for "better-together" is having BizTalk orchestrations that call out to services call MSE hosted endpoints. This shields the Orchestration from changes to the service implementations thereby reducing the likelyhood of
having to redeploy an orchestration when service implementations change.
These scenarios become more important when working with service oriented solutions were you only control half of the equation (either the service provider or the service consumer). As a service provider making sure your services are exposed through
the MSE gives you more freedom to change your services without impacting consumers you don't have control or influence over. Likewise as a consumer of a service, calling the service through the MSE allows you to limit the changes to your application
(localizing them in the MSE) when interacting with services you don't control. This also helps you more easily change providers of a service. Your application can be coded to a generic contract you create and own, and let the MSE deal with the
message/protocol translations to whomever your current provider is.
In addition, you can have the MSE leverage BizTalk components like BAM and the mapper.