Objects have behavior ( the methods ). These methods can be run by multiple threads concurrently unless the methods also enforce synchronization of some sort but the object itself does not need to be a Runnable or a Thread. Any thread's run method could invoke the said method from within its run method.
Any object can have synchronized methods/block that need to notify waiting threads. Since all objects needs to be able to have methods/blocks that can wait, notify, and notifyAll, these methods are defined in Object class.
Interestingly, neither option is entirely correct. Let me explain...
Between the two options, having wait() and notify() with the Thread object only is obviously incorrect. The wait/notify mechanism is related to the synchronization mechanism -- and since synchronization can be done with any object, you should be able to do notifications with any object.
On the other hand, having wait/notify with the Object class isn't entirely correct either. There isn't a one to one relationship between a mutex (synchronization mechanism) and its condition variable (wait/notify mechanism). For example, I can lock a data structure, but can have two conditions -- such as data structure empty and data structure full -- to do notifications on. This means that it should be possible to have more than one condition variable for the same lock.
Anyway, the correct solution is to implement a locking / condition variable mechanism -- which was done with Java 5. See the ReentrantLock and the Condition class for a complete implementation of mutex locks and condition variables..