気になったので突っ込んでおきます。
Javaにvariant型を実装したStar
なぜクラスを作らなかったっ・・・！！？

型付けをしないのは片付けないことに近い

varを扱うのは狭いスコープに限って言えばアリでしょうが、 モデル-ビュー間でのやり取りなど、スコープの広いものでは、すぐに格納されているデータの型を見失います。 静的な強い型付けの言語の強みは、データに何が格納されているかが明確である点です。

データ構造を明示しない方法論は、片づけるのが面倒臭い人には向いているでしょう。 しかし、片づけていなくても、アレはソコにある、と把握できるうちだけは問題が起きないわけですが、 ちょっと物が増えると、アレってどこにいったっけ？ということになって容易に破綻します。

システム規模がごく小さく、開発者も変わりがなく、しかも記憶力に絶対の自信があるなら問題にはならないかもしれません。 私は開発後ずっとシステムの面倒を見続けることはできませんし、記憶力にも自信がないので整理整頓をする方法論を選びます。

エスケープ漏れを防ぐ方法

フレームワークのデフォルトがエスケープになっていれば一番楽ですが、 そうではない場合はオブジェクトを格納するクラスで工夫します。

一例としては、getterに細工をして、通常のgetterは常にエスケープした文字を返すようにしておきます。 もし、エスケープされていない文字列を扱いたければ、getXXXnonEscape()といったような エスケープしないことを明示したgetterを用意します。

デフォルトをエスケープとすることでヒューマンエラーに起因するエスケープ漏れは劇的に少なくなります。

データを格納する場所で網羅することは不可能に近い。出口を網羅することも不可能に近い。 メソッド側に処理をくっつけることはアスペクト指向の概念ですね。 オブジェクト指向でアスペクト的なことをやる場合はProxyパターンを使うわけですが、 このようなデータを格納するためのオブジェクトの場合は実装そのものに載せてしまう方がいい。

Injection 系の脆弱性ってなんで起こるんだろ？ あたりも関連した話題。

眠くて文章が殴り書きですが、リクエストがあれば詳しくまとめたいと思います。