The important thing to note here is that if the user is signed in to a site http://example.com/ and the request http://example.com/delete?id=1 deletes a post by the user, then the following code will delete the user’s post:
<script src="http://example.com/delete?id=1" />
This is called a CSRF/XSRF attack (cross-site request forgery). This is why most server-side web applications demand a transaction ticket: instead of http://example.com/delete?id=1 you have to do http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess
Now the following attack won’t work:
<script src="http://example.com/delete?id=1" />
…because it doesn’t contain the txid parameter. Now, let’s consider what happens if the site could be accessed using XmlHttpRequest. The script running on the user’s browser could behind the user’s back retrieve and parse http://example.com/pageThatContainsDeleteLink, extract the txid and then request http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess
Now, if XmlHttpRequest cannot access sites having a different origin, the only way to try to retrieve the txid would be to try to do something like:
<script src="http://example.com/pageThatContainsDeleteLink" />
…but it doesn’t help as the result is a HTML page, not a piece of JavaScript code. So, there’s a reason why you can include <script>s from other sites but not access other sites via XmlHttpRequest.
You may be interested in reading this: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/
This attack worked against Gmail back in the day and allowed you to fetch the user’s mails from JavaScript code running on another site. This all shows that the security model of WWW is very subtle and not well thought of. It has evolved instead of being well-designed.
As for your question: you seem to think that the server http://example.com/ is the malicious one. That’s not the case. Using the notations of my answer, http://example.com/ is the server that is the target of the attack, and http://attacker.com/ is the site of the attacker. If http://example.com/ opens up the possibility to send requests using JSONP or CORS, it is true that it may become vulnerable to the CSRF/XSRF attack I just described. But it does not mean that other sites would become vulnerable to the attack. Similarly, if http://attacker.com/ opens up the possibility to send requests using JSONP or CORS, the attacker’s site just became vulnerable to a CSRF/XSRF attack. Thus, a misinformed server administrator may open up a hole in his own site but it doesn’t affect the security of other sites.
Edit: a valid comment was made. It explained that the following code:
<script src="http://example.com/delete?id=1" />
…sends a GET request, and that example.com should accept only POST or DELETE requests if the request changes state such as deletes something important.
This is true, a well-designed site shouldn’t change state based on any GET request. However, this sends a POST request:
<p>You just won $100! Click below to redeem your prize:</p>
<form action="http://example.com/delete" method="post">
<input type="hidden" name="id" value="1" />
<input type="submit" value="Redeem prize" />
</form>
In this case, the code claiming the user won $100 can be embedded into the attacker’s site and it sends a POST request not to the attacker’s site but rather the victim’s site.