プログラムを組み立てる上で、「こうしたほうがいい」とか「こうすべき」とかいうことは、いろいろと出てきます。ただし、それぞれのレベル感に気をつけたほうがいいです。
RFC 2119
RFCを読んでいると、よく、「SHOULD」とか「MUST」とか、すべき度合いを表現する形容詞が大文字で表記されています。そして、これらの文言があるRFCには、
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
というような定型文が付いています。それではこのRFCを確認してみましょう。
絶対的要求
MUST、REQUIRED、SHALLといった単語は、「そのとおりに実装しなければならない」という絶対的な指示で、逆にMUST NOTやSHALL NOTといった表現は「それをしてはならない」という絶対的な禁止となっています。これらの単語については、「相互運用性確保のために不可欠である場合や、 有害である可能性がある動作を制限するために限って、使用されるべき（MUST）」とされています。
推奨事項
SHOULDやRECOMMENDED、逆のSHOULD NOTやNOT RECOMMENDEDについては、守らなければ直ちにRFC違反となるわけではないのですが、もちろん推奨するからにはそれ相応の理由があるわけで、あえて外れる場合には「慎重に重要性を判断しなければならない」ものです。
日常文の中で
日常使われる文章中では、「したほうがいい」と「すべき」の明確なラインはないので、両方を一緒に考えて問題はないでしょう。それぞれ推奨される理由別に、どこまで従うべきなのか考えていきます。なお、以下の文で太字のしなければならないはRFCでのMUST相当、すべきだはRFCでのSHOULD相当と考えてください。
従わなかった結果が致命的となりかねない場合
XSSやSQLインジェクションなど、不正アクセスにつながるような脆弱性は何が何でも潰さなくてはなりません。放置すれば情報漏えいや改ざん等、取り返しのつかない事態となります。脆弱性自体の教材にするような特殊な事例は別として、有用な機能がその状況を使って動作している場合であっても、別な手法に切り替えなければならないでしょう。
相手のある場合
通信プロトコルやファイルフォーマットなどは、当然相手に読めるものでなくてはなりませんし、規格がある場合は、基本的に従うべきものです。ただし、HTMLなどではよくある話ですが、本来のフォーマットに対して拡張してあるもので、「拡張自体が有用」かつ「拡張を認識できる相手としかやり取りしない or 拡張を認識できない相手でも、拡張以外は認識できる」ような状況なら、厳密には規格違反でも拡張を利用して問題はないでしょう。
ベストプラクティス
プログラミングでの「ベストプラクティス」は、長い間に多様なプログラムの中で醸成されてきたものなので、何も考えずに無視するべきではありません。Railsで言えば「レールに乗る」と言われるようなプログラミングプラクティスですが、自分自身も触れたように何から何までそのとおりに組む必要はもちろんありません。「それに従うメリット」「従わないメリット」を踏まえて判断しましょう（なお、「保守性」などは最初の段階では軽視されがちですが、あとあとになると重要になってきます）。
やらないメリットがほぼ皆無なもの
中には、「それをしてもあまり意味がないこと」もあります。例えば、TRACEメソッドの件のように、「これが脆弱性となりうる環境はごく少ない」ケースです。ただ、この例では少ないとはいえリスクがありますし、逆にTRACEメソッドを有用な目的に使うことのほうが皆無に近いので、何かのついでに「やっておいたほうが良い」とは言えるでしょう。
「HTTPヘッダから詳しいバージョンを消す」なんてことが言われることもありますが、本気の攻略者にしてみればバージョン特定は別ルートで可能でしょうし、「セキュリティ対策」として意味があるかは疑問です（ヘッダが少し縮むのはメリットかもしれませんが）。
まとめ
「すべき」ことを何も考えずにただやるのは、すべきことをしないのと比較できる程度に危険な態度かもしれません。それをなぜ「すべき」なのか、するにしてもしないにしても理由は踏まえて進みましょう。