I tentatively suggest that inheritence should usually be reserved for fixing problems in the original design.

Well, the first project in my current job was adding features a semi-complex web application -- written in PHP. The previous developer, no doubt a good programmer otherwise, apparently felt too energetic, i.e. not lazy enough, when he wrote the original source files, because there is considerable overlap in functionality. Quite often this is because he used copy-paste to implement features on pages that lacked them. Needless to say, when I was asked to change the way some summary fields in reports are computed, I had to first manually read through all files and discover the five or six places where the same copy-pasted computation took place.

Now, the job is nice, and I've actually had fun refactoring this. My very first inclination was to abstract the common code to functions, then pass these functions around, akin to higher-level programming. However, although PHP supports lambda expressions through eval, this quickly turned out to be infeasible. Instead, I implemented a couple of shallow class hierarchies and abstracted most common functionality to (abstract) base classes. It's not beautiful or elegant, but it is much cleaner than the original -- plus adding new features is considerably easier now.

Arguably this is not refactoring the design that much; just implementing the design in a bit better way. However, it's a good example where knowing object-oriented programming (inheritance too!) saved the day.

This does sound like an example of using inheritence to fix someone else's design, but I was actually thinking about using it in the other direction: if there's some code that doesn't quite do what you need, it's sometimes very convienient to create a mutant variant by subclassing it... but if the original author was inheritence happy, you find yourself dealing with unwieldly chains of subclasses of subclasses where in order to understand what the class at the bottom does, you need to learn about all the parents all the way up the chain.

In your example, it sounds like I probably would've used "aggregation", i.e. move the common operations to methods in a new class, where the original code needs to create a "calculator handler object" (or somesuch) to access them. The advantage is that the new code is much more independant of the existing code (it has real "encapsulation").