HTTP content negotiation can be used to make client and server agree on a data format and language. Maybe you're interested in my previous question (Is HTTP content negotiation being used by browsers and servers in practice?) but it's not necessary to read.
Does this concept really make sense when developing an HTTP-based API? (An API is a web service that is not used by end users. It's called exclusively in a programmatic way.)
An alternative to content negotiation are "regular" parameters (e.g. http://example.org/myService?someParam=1234&lang=en&format=xml).
Most client-side frameworks make it very easy to call a web service and send parameters. It is often much harder to configure special HTTP headers. It seems to be more work to use HTTP content negotiation.
At the same time there is no need to negotiate. The client will be programmed in such a way that it knows what formats and languages are available. Therefore, it will only make valid calls in this regard and get exactly what it wanted.
If the server wants to decline a call it can send an application-level error instead of an HTTP error. Application-level errors are, in my experience, easier to handle. You need that code anyway. You don't necessarily ever need to interpret HTTP errors. You can just treat all of them as a generic failure.
Content negotiation seems to fit the REST philosophy well but I'm more interested in concrete costs and benefits.
In what way is HTTP content negotiation superior to just adding an API parameter?
I haven't worked with many frameworks that tout the ability to work with any RESTful API out-of-the-box. Primarily, because it is just not feasible to communicate with any possible RESTful implementation without a very broad feature for configuration, which the ones that I have seen do not have. However, that is the fault of the framework, not the API.
Working with request/response headers is essential for communicating with any well-designed RESTful API. Headers are useful for sending information like access tokens and message body signatures, and receiving information like collection size and pagination details. Why not use a system that already exists for exactly the purpose of negotiating content format? Using the full extent of the existing HTTP specification is exactly what REST is about.
About HTTP errors... why would you treat them all the same? A 404 should be handled much differently than a 400 which should be handled much differently than a 409. Either I misunderstood you, or I think you are missing some of the key aspects of REST.