C 言語だと(b)のように書くのが普通で,
(b)のほうが読み易いと感じる人が非常に多いでしょうから,
ちょっと例としては良くないかもしれませんが,
本質はそこではないことをご理解下さい.

        for (i=0; i!=sup; ++i) { ... } /* (a) */

        for (i=0; i<sup; ++i) { ... } /* (b) */

昔は, これらのプログラムの断辺の直前までに sup の値の正当性が
確認されていたとしても, 後者の様に書けと言われたもんです.
後者の方が遅い処理系だったとしてもです.
(昔はそんな処理系が本当にあったんです.)

どうも, strcpy と strlcpy の関係は, 上の2例の関係と似ている様な気がします.
なんというか, 気持としては, フェイルセーフだと思うんです.

それはさておき, 
全てのプログラムをきちんと設計して全く問題の無い製品を作れれば
それはそれでとても良いことでしょう. 
しかし, それは製品の正しさを 100% 保証するということで,
実際問題としてそれは非常に困難なことです. 

現代工学および現代の工業製品では, 製品に一定の不良率を許しています.
例えば, アポロ宇宙船なら 99.999999999% の稼働率を目標とする,
といった感じで, この場合なら 0.000000001% の場合は直ちに人命にかかわる
にもかかわらず, です.
これは宇宙船に限ったことではなく,
建造物(建物, 橋, 道路など),
乗り物(電車, 自動車, 飛行機など),
電子部品, コンピュータ,
その他身の回りにある大小さまざまな工業製品といえるもので,
その性能や安全性を 100% 保証しているものはどれひとつとしてありません.
(極東のとある島国では,
原子力発電所などは 100% 壊れないことになっているそうです.)

それがソフトウェアになったとたん 100% の保証が付いてくる,
なんてのはおかしい話です.
ソフトウェアは時間の経過で劣化することはないので,
ほとんどの場合,
壊れるというよりは不具合が発見されることになります.

ソフトウェアは工業製品ではない? そうかもしれません.
だとしたら議論はここで終り.
私はソフトウェアも工業製品だと思いたい(*** 自己矛盾してしまった...).
そして, 現代に生きる我々は, エンジニアもユーザも,
ソフトウェアについて, ある一定の不具合までならそれを受け入れるべきです.
そうした時に初めて, 
「不具合がある. そのため, 正しくはないけれども, 悪さはしないソフトウェア」
という考え方が意味を持ってくるのではないでしょうか.

同じ不具合でも, 命やセキュリティに関る不具合の方が
そうでない不具合より罪が重いとは言えませんか.
エンジニアリングでは, それらそれぞれについて
不具合の発生率を設定し, それをクリアすることを目標のひとつとします.
それができないエンジニアはエンジニアとは呼び難い.
そういう意味では, ソフトウェアの多くはエンジニアリングの成果, すなわち
工業製品ではないのかもしれません(*** ここ).

一方, サイエンスではそんなマヌケなことは考えません.
サイエンティストは「この理論が正しいなら, これこれこうなる」という
立場にたって仕事を進めます.
理論から演繹したことはその理論が正しい限り 100% 正しい,
それがサイエンスってもんです.
不具合などという得体の知れないが発生する余地はどこにもありません.
オレの理論に従い, オレの作った言語を使ってプログラミングすれば,
100% 正しいソフトウェアを作ることができる,
そう考えるのです.
(.* Software Science .* という学会名はそいう点ではチャレンジングだと思う.)

私と strcpy 派の人の感覚の違いが,
エンジニアの感覚とサイエンティストの感覚の違いでなければ良いのですが...

ところで, 私もソフトウェアを作りますが, その不良率は計算していません.
いいかげんですみません.

おわび
わざとステレオティピカルに書きました.
実際はサイエンスからエンジニアリングまでは連続していて,
その中間の様々な立場がありますし, 誰しも, 状況に応じて
立場を適切に切り換えていることが多いと思います.