そのバグが出た時の影響の度合いと発生する頻度の積を点数化して、一定の得点がないものは対処しないってのは、
普通にシステム設計する時の基本的な考え方ですね。
評価の基準をどうするかってのを決めるのがたいへんですが。

出たバグを全部潰すことを前提にスケジュール組んで見積もりを受けたのに、
結果的にバグが大量に出ちゃって、納期に間に合わないから軽微なやつは残します、なんてのは納得いかないでしょう。
だったら残したバグの分だけ金返せ、と言いたくなるのでは？

命にかかわるような装置の組み込みソフトや、金融関連などバグで引き起こされる被害が甚大になるものなどは例外として、
コンシューマー向けの製品で、ある程度複雑なものになると、発見されたバグはそれぞれ重要度をランク付けされ、
重要度の低いバグはほうっておかれてそのまま出荷されるもんだ。
致命的なバグとその一個下のランクのバグを取るので精一杯というところ。

WindowsなどのPC用OSや、ゲームソフト、携帯電話なんかはみんなそうじゃない？

Vistaみたいにそれでも間に合わなくて、リリース時期が近づくにつれ搭載機能がどんどん削られていくという
泥沼もｗ

[バグもなく、不都合もないシステムには後継が求められない]
という事かと思った。

僕自身はハード屋なのだが、
設計委託先に「設計寿命は最低5年、できれば10年以上」と要求すると
「そんなに長生きだと買い換えてもらえないアル」と反論された。
という昔話を思い出した。

# いや、そうだけどさ・・・。
    と、一瞬反論できなかったがIDで

費用対効果の概念がないので、どんな小さなバグで、つぶすのに費用がかかったとしても残すことは許されません。とくに政府調達の場合そうなります。たとえばオバマ大統領のTwitterアカウントがクラックされて、さっそくそれ見たことか [srad.jp]という反応が出てます。
ただし最初からバグをゼロにすることも許されません。テストフェーズで、予定された個数のバグを1個の狂いもなく出してから修正しなければなりません。

無いほうがいいに決まってる。
でもそうもいかないのでリスクや優先順位を考えて対処するわけですが、人も時間も限りある資源なので影響の少ないものは後回しにされ、時間という資源(納期とも言うか･･･)が尽きると放置されたりする。

残しても「良い」んじゃなくて、残しても「そのときだけ影響が少ないからこのままイキで」ってことかなぁ
言葉をそのまま捕らえると「リスクマネジメント出来てないんじゃない？」って感じる。

優先順位を決定して、納期とのすりあわせで「間に合いません」なら
そのバグは「対応しない」でなく「仕様です」って言うのが業界の常のようだし。
確かにそれでコストは増えないだろうけど。うーん。

// 泣きを見るのは使う人なわけですけど。皆が幸せになるために、潰せるバグなら全て潰したい・・・
// 技術者的には「キチンと線引いてバグを全て潰せるようスケジューリング・顧客に提案するのが一流」かなぁ、と思ったり
// まー現実はそんなに甘くないすけど(:>^

この手のやつは、
優先度をつけるときに、B(そのうち修正、なんかのついでがあれば修正)をつける。

優先度Aはマスターアップまでに直すことになってる。
優先度Aの修正が終わったら、Bに手を付けることになってる。

つまり、Aの数が少ないときだけしか、Bは直さない。
そんなことは、滅多に無い。

日本建築では完成すると後は壊れるだけだからと一部だけわざと完成させなかったりしますね。それと同じ・・・・って違うか・・。

バグの話ではないのでオフトピ気味ではあるのですが、
似たような話でコストと効果について、
大分前に見たブログ記事を思い出しました。
PS3 の性能の使い方 [cocolog-nifty.com]

要は手間（≒時間 ≒お金）のかけどころの話なんだと思いました。
# すでに多くの方がおっしゃっている通り

Aの方が重要だからBの方はやらなくていいよね。

ではないのです！AもBも両方やるのです！