RFC4448 section 4.6

Packet reordering can happen if a frame has a leading '4' or '6' Destination MAC address, going over a L2VPN PW traversing a LAG (RFC4448 states it's the source MAC, but I have yet to see this be the case).

The first nibble of the Ethernet header is the first character of the destination MAC. Also the first nibble of the IP header is the version. The router incorrectly assumes that if the MAC starts with a '4' it must be an IPv4 packet. If it starts with a '6' it must be an IPv6 packet.

Adding the control word to the PW fixes this because it forces the router to see a '0' rather than '4' or '6' after the MPLS label.

I believe this happens because the MPLS label has no field to indicate the upper layer. For instance IP has the protocol field, Ethernet has the type field, TCP/UDP have port numbers. With MPLS there is no such field, so the router just assumes an IPv4/IPv6 header comes next, but it's really an ethernet header when using PW/L2VPN.

https://tools.ietf.org/html/rfc4448#section-4.6

As it turned out, the MAC address of my RouterPi's WAN interface started with 4. Changing it to a0:de:ad:bb:ee:ff instantly fixed the out of order packets, hooray!