If something uses a bunch of different stuff (high number of afferent couplings), then it could be prone to break if any of those things change.
Instability = 1
If something is used by a bunch of different stuff (high number of efferent couplings), then it could be prone to break a lot of things if it changes.
Instability = 0
Martin's definition of "stability" is an exotic blend between "difficult to change" and "having few reasons to change". Yet his instability metric only describes "difficulty of change". "Reasons to change" will have a lot more to do with factors that can't be easily calculated, like just designing your interfaces appropriately, at an appropriate level of abstraction, and understanding user-end requirements more clearly upfront.
So high efferent coupling with low afferent coupling yields stability (as in something difficult to change since it'll break a bunch of stuff), the opposite yields instability (as in something easy to change since it won't break a bunch of stuff).
A large number of afferent couplings could be an indicator that your design lacks focus -- it's using a whole bunch of different stuff so maybe it lacks a clear, singular responsibility.
A large number of efferent couplings could initially be interpreted as a really good thing, as it indicates that your design is being widely (re)used. Yet that would be bad if you feel tempted to change the design often in ways that breaks everything. So with a large number of efferent couplings comes the need for such packages to have "few or no reasons to change". The designs should be stable in the ideal sense of not having reasons to change, since they will likewise be very difficult to change.
Stable Abstractions Principle
Concepts like dependency inversion (which naturally calls for dependency injection) and SAP (stable abstractions principle) all suggest that dependencies flow towards abstractions. And there's a simple reason why when considering the "stability" in the context of having "few reasons to change". An abstract interface mentions no concrete details, it only focuses on "what to do" instead of "what things are", and thus has fewer reasons to change. The accelerated graphics port on our motherboards (abstract interface) has fewer reasons to undergo a design change than the GPU that plugs into it (a concrete detail).
Reusability vs. Reuse
A personal kind of metric of my own if I can suggest one which somewhat collides with Martin's is this notion I like to push that the most reusable libraries should seek to minimally reuse other code. That pushes instability towards a hard 0. It's for the practical reasons of having minimum reasons to change, but also to promote the easiest library to deploy. A general-purpose, widely-used library that depends on a dozen different libraries has a lot of reasons to change, as well as an awkwardly-bundled distribution which can be difficult to deploy. The difference here is that "reasons to change" in my case extends even to implementation, as it's coming from a library-oriented view that seeks to release stable versions of the library. Martin might discount the implementation as a very separate part, and only consider the metrics associated with the library's interface (which could be a whole lot more stable than its implementation).
From a distribution point of view, implementation and interface blur together to yield user dependencies to a stable or unstable library. From an interface point of view, only the interface is used and the implementation details associated are completely separate.