> 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...