I think you've actually got there is a good rule of thumb for choosing to make a class abstract: if there are (or you can forsee the need for) variants of a class with slightly different behaviour, then it's often a good idea to create an abstract base class.

Bottom line though, in my experience: as long as the relationship you're dealing with is really is-a (e.g. your Accountant-Employee example is more suited to composition than inheritance, as per this answer) then it's very rarely harmful/problematic to inherit from non-abstract classes.

A couple of examples when you might want/have to ignore your rule. Both assume you require Poodle to be substitutable for Dog:

1. Dog is a class in an external API and there's no IDog interface for Poodle to implement.
2. Dog is already instantiated in dozens of different places in your (already tested) code.

Admittedly, these are both cases where a better original design might have helped, but in the real world designs are never perfect!

I think you've actually got there is a good rule of thumb for choosing to make a class abstract: if there are (or you can forsee the need for) variants of a class with slightly different behaviour, then it's often a good idea to create an abstract base class.

Bottom line though, in my experience: as long as the relationship you're dealing with is really is-a (e.g. your Accountant-Employee example is more suited to composition than inheritance, as per this answer) then it's very rarely harmful/problematic to inherit from non-abstract classes.

A couple of examples when you might want/have to ignore your rule. Both assume you require Poodle to be substitutable for Dog:

1. Dog is a class in an external API and there's no IDog interface for Poodle to implement.
2. Dog is already instantiated in dozens of different places in your (already tested) code.

Admittedly, these are both cases where a better original design might have helped, but in the real world designs are never perfect!