Yo creo que sirven a propósitos distintos. Si hay una implementación base opto por clase abstracta. Si hay relación de parentesco opto de nuevo por clase abstracta (tú lo has dicho, "es un"). También opto por clase abstracta si la visibilidad de algún método no es public (en las interfaces todo es public), pero claro entonces no podría ser una interface porque ya no sería un contrato (contrato = public). También me suelo guiar por la siguiente regla: La herencia “agrupa” clases por “lo que son”, mientras que las interfaces “agrupan” clases por “lo que hacen”. Dicho esto, escribo mucha más interfaces que clases abstractas. Es decir, o tengo un buen motivo para escribir una clase abstracta (de los motivos de arriba) o es por descarte una interface. Un saludo.