A VPN only functions over a single connection.
this is not true. any overlay vpn can make use of _every_ available uplink path if required. but believe me, no one on earth want to do per packet load balancing over multiple independent connections, as OOO packet delivery is a pain in the back. Mikrotik has only per packet load balancing and a quite obscure way to actually utilise this (multiple gw values in a single route entry).
You can utilize multiple connections for instance and create a secure tunnel that sends packets over whichever has the least congestion at the moment. So for instance, you're a bank and your traffic to the banking server over a VPN at the main site becomes congested so transactions slow down. With SD WAN you can bring in a second carrier (since the first would just still be congested) and maintain that secure tunnel with packets going over the fastest route. I suppose it would be more like secure OSPF.
i love how cisco (or replace this with any "big" brand name) marketing folks glue buzzwords to "destination address based packet forwarding tweaked as we need it". the whole SD-WAN movement is against the "classic" virtual pipe providers, so to replace L2 and L3 MPLS VPNs, and give a slight possibility to the customer to steer how stuff is being delivered over the remote connections. there ain't nothing new in it - and to be honest the whole L3 VPN story was found out how to fight "physical" pipes to make the service more affordable and more versatile. now you as customer can just buy any random internet connection and run your OTT VPNs on top of it. like we did back in 1999 with IPSec.
of course you have a lot more tweaks to influence how your packets/flows will be forwarded - but those are more or less convenient frontends to policy routing.
but if you can milk the whole world again - yes the ones you already sold MPLS VPNs 10-15 years ago, and IPSec prior to this, and leased lines even earlier.
and since you aren't in control of the infrastructure, you do some sort of poor man's traffic engineering - oh wait, your can just use RSVP to do the heavy weight lifting.
but inherently it's just connecting the customers sites w/o any dedicated infra. you do your best at the CPE (say, prioritise certain flows over others, do traffic shaping/bw guarantees for some other flows) and then let the good old internet transfer your encapsulated security payload to the far end. whatever happens in-between, you have no influence on that.
so customers can reduce their telecommunication out-payments to carriers and buy bigger capacity internet pipes (even some asymmetric residential service lines like VDSL or GPON) instead. as for redundancy, it seems the Internet itself is far more robust/redundant than any telco carrier on the face of earth. yet you don't need to negotiate nothing with your carrier.
glue on a point and click interface on top of it - the almighty SDN controller - which hides the complexity and there you have it. and when it comes down to troubleshooting, you just "re-provision" and hope this fixes things.
regarding the packet multiplication phenomena:
it is possible to duplicate the same packet and send it over multiple paths (tunnels) then deliver the first one arriving and drop all the others. however the performance part of this is the big burden. routers are fast, cause they push packets as simple as possible. call it CEF or FastTrack, it means roughly the same: pass the packet along the cached path AFAP. if you want to maintain states of flows, it's also possible - this is something that firewalls do right now. but maintaining states for individual packets, which is knowing that a certain packet has been received or not, is torture to them. usually routers don't care whether a packet is an OoP, they just forward it. To maintain packet states you'd need OoP detection and maybe even some sort of packet reordering buffer for each freaking flow, so you can be sure a packet sent over 3 different tunnels will arrive just once.
if you leave dealing with it to the TCP stack of the end, you end up having terrible TCP performance.
there are tools out there, like multi-path TCP or UDP based reliable transmission methods (as Google's QUIC) that can do stuff on app level, that are next to impossible at network level.
in my opinion the "SD WAN" story is a brief stop in the journey towards a more application heavy secure networking - and sooner or later most enterprises will realise that trusting application level encryption with personal internet banking can secure enough for their everyday business, and forget about the "secure" pipes. trends are anyway that you want to avoid cleartext (read: unsecured) communications anyway, regardless if they transmitted over a secure medium or not.
the wikipedia article cites stuff as VoIP or videoconferencing to be painful over traditional WAN. welcome to the future, where you can get all this stuff as a service, and it's about trust anyway. whatever can go on now, you can even get flat tariff for all your in-enterprise communications even from the big ol' PSTN operator which makes enterprise VoIP more costly - or just use a paid OTT communication provider to make sure your stuff remains private. we use webex for company and inter-company meetings w/o any dedicated infra... since _years_. i doubt SD WAN will change this. as it seems now it targets to fix some issues that already became non-existing.
and the SOHO/SMB segment already uses "services" that run in "the cloud" - and they don't need no call-home, nor interconnecting distant offices - their stuff is already is on the 'net for some time so they can access it from anywhere.