I'd recommend looking at tedious, highly repetetive tests that need to be repeated on a regular basis. For instance, if you're routinely spending several days on manual regression in a specific area of the application each time you release, it's probably a good candidate for automation.
I don't think there is a "best practice" for what should be automated, because the decision depends a lot on the application under test, the environment, legislative requirements, hardware dependencies, and potential impacts.
In my place of work, for instance, the goal is to automate as much of the transactional testing as we can - because we develop point of sale systems for a niche industry, and need to be able to handle a variety of tax scenarios for customers who face serious financial issues if the calculations are even slightly off (among other things). We focus on transactions over configuration because transactions happen more often in the live environment, and because transactions are far more important to our customers than the setup. If they need to use an awkward workaround to set up, that's not as bad as if they can't sell something.
Of course, the best internal ROI can be achieved by automating the one task everyone in your team utterly detests! (Tax regression.... at least in my world).
