サーバサイドの処理でクライアントからのHTTPリクエストを所望の通りに捌けていないにも関わらず 200 を返していませんか？例えば、要求したリソースが存在しない場合は 404 を返すべきですが、ここでbodyに Not found というメッセージを入れてステータスコードを 200 にするなどしてレスポンスを返してしまうと ソフト404 と呼ばれます。
ソフトXXXの問題点
このようなステータスコードの返し方をしてしまうとクライアント側は混乱させられてしまいます。あるAPIのSDKクライアントを作成する場合を考えましょう。クライアント側の入力に不備があり本来なら 400 が返ってくるところで 200 が返ってきたとします。本来ならこれはクライアント側のミスなのでSDKクライアントでエラーを出すべきですが、それをするためにはレスポンスのメッセージを読んで処理を分岐させる必要が出てきます。これでは無駄な実装が発生してしまいます。
ステータスコードはコードというように、わかる人にしかわからない、プロトコルという約束事の一部になります。
I'm a teapot
次のようなケースではどうでしょうか。
ここでサーバはティーポットです。クライアントから「コーヒーを入れてくれ」というHTTPリクエストが飛んできたときに、サーバはどのステータスコードを返すべきでしょうか。
418 ですね。これが 5xx ではないのはなぜかというと、ティーポットに対してコーヒーを要求するのは間違っているからでしょう。もしサーバがコーヒーとティーの複合ポットであり、一時的にコーヒーが提供できない場合は、代わりに 503 を返すべきとされています（Service Unavailable）。これはクライアント側に問題があるのではなく、サーバ側に問題が生じていたためにリクエストを処理できなかったので 5xx が返ってきているということになります。
このようにHTTPステータスコードでは100の位の値により情報を分類し階層性を持たせています。このような性質があれば、クライアント側の実装ではHTTPステータスコードの先頭一桁の値を見るだけで処理を分岐させることもできるでしょう。
コード
ステータスのようなコードは何もHTTPで使われるだけではありません。MySQLのエラーコードだったり、IPアドレスのような識別子だったり、これらもコードと言えます。
普段のプログラミングではあまり縁がないと思われるかもしれませんが、関数の戻り値としてBool型ではなく列挙型を使うことはあるでしょう。これは2パターンからNパターンのコードへの拡張であり、情報量が増えるのできっといいことがあるに違いありません。
というわけで、かくいう私も適切なインターフェース設計ができるようになりたいと思っているのでした。