Assuming we are relating to system tests, empirical data shows that the effectiveness of unit tests above 80% coverage is decreasing while the complexity significantly increase, I am not aware of any magic number for coverage.
But let's take a step back and analyze your question.
First we need to understand what coverage is. Having one test per requirement doesn't take into consideration ranges and timing for example, measuring the actual code coverage of your system tests is usually not practical and while better it still doesn't guarantee that your business logic is covered.
Next you ask about "what should", to answer that you need to know first why do you care. Do you think that higher coverage is better? why? Hard scripted Tests in general, and automated tests even more, tend to have a "pesticide effect" meaning that they are not really good at finding new issues, and while they are doing a better job finding regressions even this is quite limited to bigger problems.
The last question needed to be answered is the cost of achieving higher coverage (cost means effort, resources, time etc.), writing the first automated test is hard and costly since it requires setting up of a test infrastructure. From there the cost is usually low, especially when adding related tests using the same mechanism, think Selenium and POM- most of the tests are about manipulation and interaction with locators. But the low cost trend stops somewhere when complexity increases, the test's runtime increases or you need a sophisticated infrastructure to simulate special conditions. In a typical Pareto principle the cost of the last added percentages towards 100% will be significantly higher than the lower percentages of coverage.
Now you are probably asking what should your team do. The answer depends on the structure and way of working in you company and team. A fast pace, Agile team with a new product and few people responsible for automation can be satisfied with few valuable, fast and stable regression tests. A legacy product with a a lot of available test resources might want to achieve higher coverage, I really like the SQlite example with "Millions and millions of test cases"