>>65-67
> 継承関係に関しては明確に必要な場合か
> 事前のアーキテクチャ設計方針で決まってる場合以外には使わないかな

これは明確な回答ですね。
つまり、例えば大学の学生証管理システムだとすると、Studentクラスで直にコーディングして、
後にアーキテクチャ設計方針がひっくり返されて「教授も身分証作ったから足してくれ」となった場合は
Person→Student, Person→Professorのような継承関係にするわけですね。
それまでにStudentに直に結び付けて作ったメソッドなどは一部作り直しになりますが、そこは許容するスタイルですね。

> インターフェースに関しては依存性の方向を変えたかったり
> 結合度を下げたかったりする明確な理由があれば良いと思う

> あるライブラリを後で違うものに入れ替えられるように作っておきたい

…と言われると、依存性は低い方が良いに決まっていますし、
あるライブラリを後で違うものに入れ替えられるように作っておいた方が良いに決まっていますよね？
そして、未来は予測できないので、その工夫が後に活きてくるか無駄になるかは不明です。
つまり、

> 入れ替え可能にする手間や増加するコードの複雑性と
> 呼び出し側の変更なく入れ替えが可能な柔軟性とのトレードオフ

つまり、工数として、
　入れ替え可能にする手間や増加するコードの複雑性　＞　呼び出し側の変更なく入れ替えが可能な柔軟性
か
　入れ替え可能にする手間や増加するコードの複雑性　＜　呼び出し側の変更なく入れ替えが可能な柔軟性
かは不明です。

このトレードオフをどのように決めていますか？
>>62-63さんは「今、不要な機能なら要らない」という指標を示して下さいました。