Well, to illustrate my point just look at the WebDAV spec vs the HTTP spec. WebDAV shows how you can add more semantics to HTTP response codes.
But when you think about it, for a pure REST API you really only need classic HTTP response codes.
Response codes only make sense in the context of a resource. Once you introduce query strings or start to stretch the meaning of HTTP verbs the abstraction starts to leak.
So when designing an API it's smart to just handle errors at the application level rather than at the protocol level.
Protcol level errors are for things that are outside of the application. An error response with data validation errors should return a 200, for example.
If any meaning is going to be taken from them at all, then the difference between "OK" and "Server Error" seems pretty basic and fundamental.