Apart from spelling Geoff's surname wrong there are a few misunderstandings in the article.
RFC 6824 takes NAT into account and has a whole chapter (6) dedicated to middlebox interactions. Of course a sufficiently stupid middlebox can break anything, but MPTCP will then just fall back to regular TCP with a small delay. Keep in mind that each subflow is (almost) a regular TCP session for everyone but the two end hosts. One can probably assume that they tested this on at least the most common middleboxes out there.
The primary use case for Apple is probably resilience and not more bandwidth, i.e. being able to switch seamlessly between two otherwise unrelated connections and only being minimally affected when one disappears.
The chicken-and-egg part isn't much of a problem. We're talking OS level stuff so the application developer doesn't have to decide. And since everything is backwards compatible you can implement it little by little. Compare it to TLS for SMTP.
Regarding VPNs and security, MPTCP also takes this into account. A new subflow cannot send data before the other end has been verified as the original partner. Trying to create the subflows will leak information about the other end's address(es) but VPN software could prohibit this like any other NAC feature.