Debug.Logやprintはデバッグのために非常に役立ちます。
重要な処理をする前後に置いて処理が正しく終了まで到達したかを調べたり、 UIがない画面での処理結果を表示したりして確認に使えます。

使いやすくて色々な所に書きすぎることになるかもしれません。そうなってくると便利なはずのログがとたんに牙をむきます。どのログが重要なのかがわからなくなり、あまりに多くなってくると無視しても良いのだろうかと疑念を抱くことになります。
作るときに仮に置いたものなどは役目を終えた時点で破棄していくべきですが、そう簡単に消しきれないこともあります。

Debug.Logをそのまま使うのではなくこれをラップしたメソッドを作って、それを呼び出すようにするのが良いと思います。

public void MyLog(string message)
{
Debug.Log(message);
}
とかでも十分です。 こうやってDebug.Logを呼ぶだけだと変わらないと思われるでしょうが、MyLogを通して呼び出していることが重要なのです。
色々な拡張ができますが、MyLogの中のDebug.Logをコメントアウトすれば、ログが出なくすることもできます。 前後に余分な情報をつけるといったことも簡単です。自分で改造できるメソッドなので、直接Debug.Logを呼び出すよりも融通がきくわけです。

ログをカスタマイズするという意味では上の方法で良いと思います。ログをリリースまでは出しておき、リリース時になくすというような使い方をする場合はConditional属性を使うとより良いと思います。 

[System.Diagnostics.Conditional("MY_LOG")]
public void MyLog(string message)
{
Debug.Log(message);
}
というように書きます。 このようにするとMY_LOGというシンボルが定義されているときにMyLogは実行されます。色々なところでMyLogは他のメソッドと同じように呼び出すことができます。使う側では特に意識することなく使えるのにシンボルが定義されているかによって呼び出しが行われなくなるというのが使いやすいのです。

#ifを使っても似たようなことはできます。
#if MY_LOG
public void MyLog(string message)
{
Debug.Log(message);
}
#endif 
とすればいいのですが、呼び出す側でも#ifで囲わなければなりません。Conditional属性を使うと、これがなくても良いのでコードが読みやすくなり、書く分量も減ることになります。