Actually it can make a lot of sense to do it that way. Imagine a class with two methods. You supply default code for both but at no time should any user of the class use the default code for both. You would always want them to supply code for at least one of the two methods. By making the class abstract, you prevent the user of the class from instantiating the class thus giving them a big clue that one of these things should never exist on its own.
There are real examples of this in the JDK. MouseAdapter has no abstract methods but is itself an abstract class. The reason is that it supplies default behavior for all mouse actions (no behavior) but
you should never actually code a program to use a mousse adapter if you are going to ignore all mouse events!