These measures help a great deal to understand the code base. However, to really know where "the dragons live" in your code base, you want to combine these measures.
Instability Over Code Coverage
If we are going to have a class that, for whatever reason, is going to have a high level of instability, we had better make sure changes to that class are done very carefully, just as you would very carefully make changes to a load bearing wall of your house. Having high code coveragethat is, making sure that unit tests exercise as much of the code as possible, is especially important when dealing with classes that have a high instability index.
Classes that have high instability and low coverage are far more likely to be a source of defects upon a change than average. If you are trying to stabilize a legacy code base, adding test coverage to the most unstable regions is some of the lowest hanging fruit.
Instability Over Cyclomatic Complexity
Classes that have high average cyclomatic complexity per method and high instability tend to be the most significant sources of software defects, especially if there is no code coverage to help identify the bugs before they are put into production. It is likely that many systems could be stabilized a great deal by adding code coverage to the highly unstable classes, and then employing re-factoring efforts to reduce the cyclomatic complexity of those classes to further reduce the ongoing defect risk.
Is Coupling Always Bad?
It should be noted that all systems will have some level of coupling, instability, and complexity. That is part of the nature of software. The key is to reduce these measures where you can, making sure you have only the essential complexity and coupling to provide a solution, without adding needless complexity or coupling. As well, you want to make doubly sure you have coverage in areas that have high coupling, and do everything you can to reduce cyclomatic complexity in those areas.