The key factor is not technical ability, but cost
Other answers have given good insights into the kinds of tests that can be readily automated, and those that can be performed better (on a technical/quality level) using Manual QA. However, I feel one key thing that is often missed is that the real decision is never "can we automate these tests", but "is it more cost effective to automate these tests".
When developing a test automation strategy, the goal is exactly the same as a manual testing strategy - to increase the product quality.
Similar to moving QA away from developers, to dedicated QA staff. Automation is not a move that directly increases quality by itself. Instead, it is simply a different way to achieve the same quality increase - which has different costs associated with it.]
Importantly, given enough time and resources - automation can be used to perform all testing on a project. However, the cost associated with most of this testing is far higher than hiring manual QA to test the same areas.
Note, that cost here does not exclusively refer to monetary cost; but also the time required and how that impacts the release schedule of your product
As such, in any situation when considering what "can" and "cannot" be automated - the real question that needs asked is; in what areas would using automation be more cost effective than using manual QA.
When determining which areas may be appropriate for automation, some key criteria may be:
- Is your product a single release, or a long-term service?
While development is ongoing, and features are being changed - automation will continue to require development to meet the changing requirements. In a single-release product, such as video games, the time spent developing most automation may never pay off; as testing finishes soon after development finishes. Manual testing has the advantage of flexibility - where humans can pick up any build and continue to check it. In a long-term project with only minor changes - automation costs can be recouped by running for years with only minimal maintainence, and will likely become cheaper than the equivilent manual testing.
- Do you have any simple functionalities involving large amount of data?
In areas which are simple to test, but involve large amount of varied data - automation development costs may be low, with large payoffs. For example, testing that every one of 1000 configuration files loads without error - may be simple to develop as an automated test, but would have taken manual QA multiple days to check through. Likewise, localisation testing involves checking the same functionality for each language - if the automation can run in one language, it's likely to take no extra effort to run it in all others.
- Do you have functionality where failures cause large knock-ons?
*For some products, there may be areas in which a failure will cause large knock-ons to future development and testing. For example, if the product takes 2 hours for manual QA to download but is untestable if it crashes on launch - automating this simple check may provide value in the reduction of lost-time for manual QA (every build your automation catches early, saves 2hours x number of testers, hours of wages).
- Do you have legal requirements that need met?
For some products, the cost of not testing needs to be taken into account. While automation may be more expensive in the average case; it is sometimes necessary to compare its cost to the worst case. That is, if a manual test failed to catch a bug, which later makes your company liable to be sued - the cost of automation may be justified by the reduced risk, despite being more expensive than almost-equivilent manual checks.
There is no solid rule for what should and should not be automated. Each company pays different amounts for their manual QA, and for their automation developers - what makes financial sense in one company may not make sense in another, even with identical products.
As a final rule of thumb:
Automation can be considered to be an investment, which needs to be run repeatedly to pay-off against manual QA. That is, Automation scales starts expensive but scales well.
Manual QA is a flat-fee, which often starts cheaper than automation - but continues to be cost throughout the project. That is, manual QA starts cheap - but scales badly.