Here's my 2 paise:
In Java the Object class is a concrete class. Now my question is why did the designers of the Java API make the Object class a concrete class.
According to the GOF design principles one must always program for interfaces and not implementation. The designers of the Java API could have used abstraction here which is one of the OO principles.
If everything in Java is an Object implicitly then why is the Object class a concrete class? It could have be an abstract class with common methods sitting in the Object class. It could have also been designed as a skeleton class where it implemented an Object interface and provided a skeletal implementation in an abstract class called AbstractObject similar to the way the Collection classes have been designed.
To clarify, creating layers of abstraction helps you simplify the root problem you are trying to solve - the classic example being high level language vs. machine language. Programming to an interface is essentially defining a contract which your code will adhere to. A contrived example would be 'provided a motherboard supports PS/2, I can connect any mouse with a PS/2 interface to it.' The motherboard doesn't care whether the mouse uses a ball or a laser. Indeed, you're free to change it at any point, because the motherboard isn't aware of the implementation details. All it knows is the interface.
When deciding whether to make a base class abstract or not, I have a simple rule of thumb. I ask myself, 'Is there something I need to force child classes to do in a manner which I can't predict?'. Well, actually that's the second question. The first question is, 'What's changing and can I encapsulate it?' - some standard patterns which help answer this question are the strategy, visitor and command patterns. More often than not you shouldn't need an abstract base class. Favour composition over inheritance and all that...
But back to the second question. What is it that Object says every derivative class must do? In Java, these are described by methods like equals(), hashCode(), getClass(), toString() etc. Now which of these methods can the Object base class not provide a default implementation for? None of them - they can all be given default implementations very easily. Therefore there is no case for an abstract class.
The last part of your question is about using an Object interface and an AbstractObject. In the context of all that I have already said, the answer is 'We get nothing extra from creating an interface and an abstract implementation. So why bother?' or in short, YAGNI.