Ohh I dunno. Lets say you're running a non-HTTPS site and an attacker MITMs one of your users and injects JavaScript which will appear to come from your site into that users session.
At that point the attacker can use that JavaScript to send your user's data to another server under their control, same origin won't help, as the JavaScript will appear to come from your site.
Man in the middle attacks allow an attacker to read data over the wire. It does not mean the attacker and modify that data. It certainly doesn't mean the attacker can move traffic to a different end point.
Usually man in the middle attack refers to an attack where someone controls a connection between you and the server and is able to freely control the connection including modifying or completely fabricating any packets coming through. Your ISP and whoever controls the wifi router you connect to can modify any data coming through like this.
Same-origin is the other way around, it protects evilcorp.com from being called by non-https.com. So a simple CORS setup on evilcorp.com would indeed allow you to send all user data by MITMing non-https.com
CORS allows a site to bypass same origin policy according to a whitelist specified in the corresponding HTTP header. The setup on evil.com is irrelevant. CORS must be instantiated from the server sending the page.
No. From your link: "Note that in the CORS architecture, the ACAO header is being set by the external web service (service.example.com), not the original web application server (www.example.com). CORS allows the external web service to authorise the web application to use its services and does not control external services accessed by the web application."
It doesn't because Same-origin protects data on example.com, not on the embedding page (in your example). It is not a security measure that aims to prevent the issue mentioned by the grand parent post
