One of the cool features of MPTCP is its dynamic behaviour - without any complexity in configuration. E.g. add two outbound connections via Ethernet and three LTE usb sticks and as long as each individual connection itself is configured correctly, MPTCP will do the rest including failover between links, bandwidth aggregation and so on. Cool stuff!
Are you sure?
Everything you mentioned would be true for connections originating from the Mikrotik itself - say if it is going to execute a fetch or maintain an ssh connection to a remote host.
Unless I've skimmed over it, the RFC says nothing about a middlebox participating in the task.
In fact, the RFC calls for cryptographic handshaking on each subflow to authenticate the endpoints, and uses tokens in order to be able to detect and penetrate a nat.
MPTCP is a layer 4 protcol, which is end-to-end.
What you're thinking about is pretty much an entirely new thing which would use MPTCP as part of its solution - namely, that it would silently terminate a tcp socket locally in order to originate a new mptcp stream outbound, and then forward the data between the two sockets transparently.
In fact, the Mikrotik would be forced NOT to break into mp-capable handshakes going through it. (what if the internal host has another link that doesn't go through the mikrotik, and it's already started an MPTCP session- the 'tik won't have the right cryptokey for adding/removing sub-flows.)
EDIT: Don't take this post to mean that I'm against MPTCP - I think it's awesome. I just don't think this is how it works.