ハードウェアの開発設計者であれば確率統計をベースとした推定、検定の類の知識を有して、それを実務（製品などの開発設計や品質の管理などの仕事）に活かしておられると思います。
この辺りの知識は、エンドの製品やサービスの品質に直接影響する＝ビジネスに直結するため、プロの技術者にとって必須といえるものだと思うのですが、ことソフトウェアの分野に関して言うと、あまり要求されることがありません。
ソフトウェアの関連でもMTBF（平均故障間隔）にまつわる説明理解の周辺で若干必要であったり、検査における残存バグの推定などの辺りで知識が必要であったりしますが、通常の仕事の場面で確率推定や検定を振りかざして議論など起こる場面はあまり見かけません。
ソフトウェア製品の場合は経年劣化により破損などは起こりえませんし、外部要因による強制的なデータなどの変更（放射線照射などによるビットの変化）は特殊な状況で使用される製品を除きまず考慮されません。
基本的にプログラマなどの意識としては、「コードにバグがあるなら、障害は起こる」といった感じでしょうし、裏を返せば「コードのバグを無くせば、障害が起こる確率は０である」（あたりまえ）と思っているはずです。
そのようなこともあってソフトウェア技術者の意識としては、確率が仕事に絡んできてその知識が必須という認識は薄い気がします。
現実は「コードのバグは０にするのは極めて困難（金が掛かりすぎる）」ですし、「コードに内在するバグが障害として発症する条件が整う確率」も実際の使用状況から考察することもできなくはないことですので、ビジネスの視点で見ればリスク対応のためにもソフトウェア開発にも推定、検定を利用して有効（有利になる）な場面が多いと思えます。
実際のところISO9000シリーズやISO26262などでもこれらの知識を要求する場面があるので、ソフトウェア技術者も十分な理解を必要とするはずです。とはいえ、多くのソフトウェア技術者はやっぱりまだこれらを使える有効な武器としては認識していなさそう。
ちなみに、この辺りの知識を有するとミスター・スポックではありませんが「キャプテン、そのバグがこの顧客のところで問題を起こす確率は９５％の確率で０．００１％です」とか言えるようになるわけです。
;;;「キャプテン」を適宜「課長」とか「部長」とかに置き換えてみるとよろしいかと。
;;; もちろん推定のための情報は必要です。