The use of the word "abstract" in "abstract class" comes from the notion of abstract data types, introduced by Barbara Liskov and Stephen Zilles in 1974 in their paper "Programming with abstract data types" [0], which starts with a section "The Meaninng of Abstraction" (after the introduction). A simplified summary is that this is about having an interface that abstracts from implementation details:
> We believe that the above concept captures the fundamental properties of abstract objects. When a programmer makes use of an abstract data object, he is concerned only with the behavior which that object exhibits but not with any details of how that behavior is achieved by means of an implementation.
It seems to me that the term "abstract" is justified for abstract classes whose role is to define an interface. (Note that pre-Java "interface" was not a language construct, i.e. the Java equivalent of "interface" is an abstract class in C++.) The article argues that "abstract" should only be used when "details are left out". However, abstract classes leave out the implementation (or at least part of the implementation), so they inherently leave out the respective implementation details.
My point is, it is important to understand where the established terms come from, and what is meant by "abstract" in the context of abstract types [1].
> We believe that the above concept captures the fundamental properties of abstract objects. When a programmer makes use of an abstract data object, he is concerned only with the behavior which that object exhibits but not with any details of how that behavior is achieved by means of an implementation.
It seems to me that the term "abstract" is justified for abstract classes whose role is to define an interface. (Note that pre-Java "interface" was not a language construct, i.e. the Java equivalent of "interface" is an abstract class in C++.) The article argues that "abstract" should only be used when "details are left out". However, abstract classes leave out the implementation (or at least part of the implementation), so they inherently leave out the respective implementation details.
My point is, it is important to understand where the established terms come from, and what is meant by "abstract" in the context of abstract types [1].
[0] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136...
[1] https://en.wikipedia.org/wiki/Abstract_type