I think in UML the difference is in that "extends" is based on extension points, which means there has to be a named point in the use case where the extension will be applied. The semantics are not very precise about this. Inheritance for use cases means changing some behaviour, not exzactly specifying where.
Another important point is about the inheritance and the Liskov substitution principle. You should be able to use one use case, which inherits from another, in any place you can use the another one. This does not hold for the way "extends" is understood. When one use case is extended by another, it means that one might be modified by another, but still it contains the main scenario path, which might be forked and joined by the extending use case. This is, I think, about the difference between structural and behavioural inheritance. Inheritance is about achieving the same goal and satisfying the same interests - same responsibility and behaviour constraints, where extension is about modification of the structure of the path of scenario, which might be triggered by additional interests - like error checking.
Inheritance actually is not a very good mechanism to be used for use cases, combined with actor inheritance, which makes more sense, it can lead to unwanted paradoxes. Following the advice of Alistair Cockburn (Writing effective Use Cases), inheritance should be used only for expressing variations in technical details or data formats for a particular use case.