> TryCatchで括ってFinally句に開放処理を書いておけば大丈夫な気がします…。
Finallyブロックが処理されないケースもありえます。（強制終了時や破損状態例外など）
https://dobon.net/vb/dotnet/beginner/tryfinally.html
https://msdn.microsoft.com/ja-jp/magazine/mt620018.aspx


> 仮にファイルをロックしたままApplication.Exit()したり、タスクマネージャーから強制終了しても、ロックは解放されるようなのですが、なぜなのでしょうか。

AppDomain が Unload される際にガベージコレクトされるためです。
ただしそれはマネージコードの世界だけなので、アンマネージには適用されません。
たとえば解放順序を守る必要があるようなコードの場合、その順序が保証されるとは限りません。


> 整合性が取れたオブジェクト、という言う意味がもう分かってません。

強制終了で問題になる具体的な事例はすぐに思いつかなかったのですが、
整合性という点で言えば、たとえば、NumeriUpDown と言うコントロールが思い当たります。

このコントロールは Value プロパティで数値を管理しているわけですが、
入力制限のための最大値(Maximum)および最小値(Minimum)のプロパティがあり、
　Minimum ≦ Value ≦ Maximum
の範囲になることが保証されています。
範囲外となるような設定はできず、これが「整合性が取れた状態」にあたります。
（DataSet の EnforceConstraints プロパティのようなものです）

とはいえ、フォームデザイナーに貼り付けた時などにおいては
一時的にこの制約が取り除かれた状態が許可されているのですけれどね。

そしてこの制約判定はスレッドセーフではないため、判定処理中に
値が変化してしまうと、「整合性が取れていない状態」になりえるでしょう。


> WindowsFormアプリケーションはどういう仕組で、その安全性を保証しているのでしょうか…？

保証されていません。たとえば Excel で書き込み処理を行っている最中に
アプリが強制終了されると、ファイルの一部が不整合な状態となることがあります。

最近の Excel では、バックグラウンドで作業状態を自動バックアップすることで
そうした障害に備えるようになっていますが、それらの整合性は OS レベルではなく
アプリケーション側で対策が求められます。