以下は、あくまで個人的な感想です。
これは作るアプリケーションにも依るとは思うのですが、開発ツールに更新があった場合、すごく怖いのは細かいロジックの動きが少しづつ変わってたりすることです。これは、大方コンパイルの時警告が出たり、エラーが出るので把握可能です。今回はライブラリは同じなので、問題ないと予想されますが、意外にユニットテストを再度行わないと見つからなかったりします。一般的に、四捨五入が銀行方式に変わるとかそんな大きな変更は、リリースノートにデカデカと書いてありますが、それでも運用してから初めて気づくなんてことも……（いちいちリリースノートを上から下まで読んでいる人がどれだけいるか＾＾；）
あと、これも頭を痛めるのは、便利なコントロールやサードパーティ社製のツールが新バージョンをサポートしてなかったり動きが変わってしまうこともあります。
これらは、単体テストでは発覚せず、使ってみて初めてわかる部類の違いが多かったりします
以上から、私は、単体テストのみなならず、一通りの画面や機能はチェックすべきだ、という立場です。
これは、会社やアプリのポリシーなので何とも言えません。
個人的な感想としては、開発側が動くことをテストやツール会社のサポート条項などでエビデンスを出さない限り、受け入れ印は押しません。
私もAzuleanさんと同じで、開発ツールなどの更新は、アプリ自身のライフサイクルに合わせることをお勧めします。
アプリ改修時なら、テストも一緒に行うでしょうから、別途テストを行うコストが削減できます。
＃正直、自分が個人で作って公開しているようなアプリであれば、コンパイルが通って動けばそれ以上のことはしないと思います＾＾；
＃TDDなどで、テストクラスを作っておくと、このような時の回帰テストのときチェックがかなり楽です。
＃あと、WPFにすると、アクセシビリティクラスを使って画面や機能全体のUI動作が必要なチェックも自動化のためのクラスをかけるのでとても楽。
##（たぶん、自動的なテストはエビデンスの一つにはなっても、それだけで受け入れ印押してくれるところは少ないと思いますが＾＾；）
