It's less about routing and more about connections. Typically, your client makes a single TCP connection for HTTP communication, all data requested on that connection is communicated on that connection. With a supporting server, multiple TCP connections can be used for the same HTTP connection. This doesn't help with transfer speed, but it improves TCP's ability to route around failure. One of your multiple TCP connections goes out, and another one (presumably on a different route) continues handling data transfer. With regular old TCP, the connection tends to fail and has to be re-established.

Pointless Pontification: since TCP was designed to route around failure, multi-connection TCP sounds to me like an adaptation of technology to the "demands of business." What I mean is network operators seem to want to centralize their networks to reduce costs instead of distributing them to make them robust, thus the technologists are attempting to work around this "failure."

It doesn't make sure the nodes along the route do not drop the packets. Nodes along the route would see those packets as normal TCP packets (which is by design because in this way routers in between don't have to change). But both end are aware of MPTCP and they may use multiple path.

In this case, iOS is connecting to Siri server using both 4G and WiFi. They apparently go through different routers. This helps improve reliability when the device is at border of a WiFi coverage and is switching between 4G and WiFi back-and-forth. Using two path simultaneously would allow Siri to switch to the other route when one of them is showing significant packet loss.