The idea of the Observer pattern is to allow an object to register for updates from another object, without the other object having to know about the actual type of the observer.
In statically typed languages such as Java or C++, this is done by having the class of the object that needs to register for updates, inherit from the Observer class or implement the Observer interface. This is so it could be regarded as an Observer and register as an observer to any class that allows this, without that class knowing about the actual type of the registering observer.
The class allowing objects to register for notifications (called 'the subject') provides a public method
registerObserver(Observer o), and thanks to Polymorphism any class that inherits from the Observer class or implements the Observer interface can register.
The Observer class or interface will have a method
notifyObserver(), which the subject can call on all the observers registered to it - again, without caring about their concrete type.
This shows you that it makes no sense to instantiate an Observer on it's own. And this is why you define the Observer class as abstract, or in single-inheritance languages as an Interface.
Also, keep in mind that in single-inherited languages such as C# or Java, it's much better to define an Observer interface, and not an Observer class, because if a class inherits from Observer it can't inherit from anything else which is very limiting. However some single-inherited languages support Interfaces, so your classes can implement an Observer interface while still being able to inherit from another class.
Another thing to remember is that conceptually, a class defines an object's type while an Interface defines what an object can do. All your subject cares about is that objects can observe it, it doesn't care what they are. So conceptually an Observer Interface is a better option than a class (unless you use a language like C++ which doesn't have Interfaces but has multiple-inheritance).