The role of coverage is to provide a metric that can be used to determine the completeness or adequacy of the verification process. There is no coverage metric that is both complete and practical. Path coverage is the only metric that could be argues to be complete, and even then with a number of additions to handle concurrency, because it maps every possible path through a design. Using this as a metric would be very similar to formal verification which also looks at every path in order to prove a property of a design. Formal verification often fails because this becomes too large of a problem.
Thus a more pragmatic approach has to be taken. Code coverage provides a set of easy to implement metric, but these are only good at identifying functionality that has not been exercised. They cannot identify missing functionality because they are based on the source code of the design. Path coverage also suffers from this limitation.
Functional coverage provides a model of coverage that is independently defined and thus the inability to hit a coverage point may be an indication of missing functionality. Assertions can also be used for coverage.
In addition to these coverage metrics, many ad-hoc metrics are also in common usage. This may include bug rates, hours of verification performed without finding a new bug etc. These tend to provide a measure of code stability and provide a different form of assurance about the design. No company would use only this kind of metric.