We could give an arbitrary number not knowing your context, e.g. 80% should be automated, but that wouldn't make any sense, since the answer to "how much to automate" depends on many variables, i.e. your schedule, how much time and resources do you have to automate, etc.
The question is closely related to "what makes sense to automate," which requires a separate discussion.
There's a growing push in the Agile community towards continuous deployment. In this scenario, you need 100% automation because the deployment process begins once code gets checked into the main branch.
My answer is automate anything possible even if it can be tested manually quicker. This will reduce regression technical debt in future builds.
Usually the only reason not to automate is not a technical one but more of business needs and lack of resources.
Here I would like to share my experience: Well in my experience, we automated piece of code which we would test frequently and repeatedly. We also automated remaining functionality which we would not need to check repeatedly and observed some times that it was overhead to check it through automated scripts. Well this can't hold true for all applications and all scenarios. Ours application was a complex one and features were complex too and there were other factors like availability of client environment, performance of network, communication/linkage b/w application and automation scripts which also contributes to this problem.
Hence the bottom line is based on your requirements and usability of that automation you should decide what to automate up to what extent [img]/images/graemlins/smile.gif[/img]