- Checking for scripting errors with JSLint becomes easier.
- Code reuse between pages becomes simple.
- Centralised hosting of common files becomes possible. (e.g. Google Libraries API )
- It's being used to generate links or other dynamic content on the page.
- Your scripts are so big that they drastically increase page load time.
If you make it an external file, then they have to download it once, which is slightly slower than including it in the page, because of the extra HTTP request. However, after that, it will be cached and they don't need to download it again.
In terms of the impact on SEO, that's the benefit - your site is quicker, which Google rewards greatly.
- One-page sites. The same caveat applies as to arbitrage sites.
For code management, you are still best to develop with the code in an external file and then use a deployment script to grab the code and insert it for the production version of your code.
Finally, shared libraries like jQuery should always be external, because they will often already be cached in a visitor's browser from another site they visited.
There are two additional reasons for external JS files.
Caching. Once an external JS file is downloaded by the browser for the first time, it stays in browser's cache and the same code does not have to be downloaded every time a visitor reaches a page that she has not opened
Code management. If you want to change your script, you do it once, by modifying the JS file. The same effect may be obtained by server-side inclusion directly into an HTML document but the advantage of caching (point (1)) is not there anymore.