I would say that the observer patterns loose the coupling some what.
But only in one direction. Still the observer (the listening object) has to know who is sending the message and register at the subject (the sender) to listen at that objects specific message.
Also, the interface of the sender must not change, it may break the whole ting for all listeners. If we also have a lot of different listener, all have to reimplement the new interface, witch my take some time if all other has other things to to. Then we end up with versioning of the messages.
However, still useful pattern. I though not think it has so much to do with decoupling objects and making them independent from each other.
I also think that it is interesting to discuss weather to send data in the original message or just sending the event and ask for data later.
Sending data at once makes mor dependencies, this thing with breaking the contract stuff. Supporting more and more different objects tend to make the signatures of the messages that contain data bigger and bigger. And then more and mor using them and then changing them - terror. Since the observer have to know about the sending object, the subject can contain both the possibility to send small notification messages and offer specific methods or properties to offer data. In that way the breaking contract stuff getting a little easier to handle.
So the observer pattern is not so much about making objects independent of each other, but more about optimising (minimising) calls between them. That is ok, and good. 
But it is that.
For more independence there are other patterns.
Is this even an interesting discussion to have here?