Something like this makes sense for JSONP, where you can't use HTTP status codes because the handler for the JSONP response doesn't get called at all if the status code is anything other than 200. In this case embedding a "status" field in the response is necessary to communicate errors.
If an ill-conceived client sends HTTP requests yet drops HTTP status codes on the floor, I have no doubt that coddling it by also breaking the server (200 OK, {"status":"fail"}? wtf?) will catch on despite being an amazingly bad idea. This is why we can't have nice things.
Many modern-day streaming protocols are built on top of HTTP purely because firewalls don't block it and proxies can forward it. Obviously that's a terrible idea from a performance point of view, but it's a fact of life that things are broken and we can deal with it by moving up the protocol stack.
Feel free to try and make (400 Bad Request, {"details": "whatever"}) work when your Javascript code is injected into someone else's code running on their own domain. If you can - and not require users to be using a particular browser version - you will make mashup and browser extension authors very happy.
If I really wanted to cater to such insanely reckless third parties who can't proxy through their own servers, I'd leave my real services unchanged (so they can still be consumed by non-broken clients) and add a js proxy service that can call any of my real services, and return a response with js that stuffs a description of the real response into an object supporting the XMLHttpRequest interface (especially including getResponseHeader(), status, and statusText). That way the caller can treat XHR as a uniform API for handling responses, even for those cases where they had to resort to an ugly hack rather than XHR to actually get the request on the wire.
