Using error codes instead of text messages makes sense, in my opinion, in a context where they are used internally. Things would be very different if you were developing a public API—other developers won't enjoy working with cryptic codes instead of human-readable, explicit error messages. The benefit, with integers, is that you're saving some bandwidth; are the savings that important is a separate question (and I hope you know the answer to it).
I'm not sure what do you mean, however, by “stringly typed” data. Since your question is in a context of a Web API, I suppose that you're communicating through XML or JSON, which means that everything is a string. When you're sending a error code 260, you're sending something like:
"error": "Bad request",
as opposed to
[0xF0, 0x02, 0x00, 0x00] (or the other way around, depending if you use Big-endian or Little-endian), isn't it? So it's a string. It is presented to your application as an integer, but only because the serialization library converted it to one. In the same way, it could give you a value from an enum.
Back to your question about the possible drawbacks, here they are:
You're increasing a risk for developers to make a mistake. It's not that difficult to make a mistake of thinking that error 422 means “Customer ID is outside the range of allowed values,” while in fact it means “The customer with the specified ID was found, but is currently marked as disabled.” If the error message is “CustomerIsDisabled,” it would be much more difficult to make the same mistake.
Small mistakes like that often cost quite much. It is not unusual to waste several hours trying to debug an issue, and then finding that you're on a completely wrong track because you thought something which appeared to be something else.
For this reason alone, it would be preferable to use explicit error messages as much as possible.
You're maybe making it impossible to add metadata. If (and only if) the response contains a single value (either a error message or a error number), then the string variant has a benefit of allowing extra data to be added within the error itself.
If you can add metadata side by side with the error code, then the error code is fine:
"error": "Bad request",
This, by the way, would be better than a simple error message such as:
Operation blocked until 2019-05-24T14:52:50Z, because the user exceeded the allowed limit of 100.000 changes for the day, the current usage being 100.027.
because if the consumer wants to do something with the metadata, it would need to parse the error message and extract the data, instead of just accessing it as is.