1 については、そもそもの前提が違うのかもしれませんね。

たいていのログは何か問題があったときに書かれるだけなので、それを監視して分かるのは障害が発生したということだけで回復というものがありません（もちろん、障害とそれに対応する回復のログが出るものもありますが、それはここでは考えない）。

このため、ログ監視をすると、障害となるログを検知してアクションを発生した後もトリガーの状態が「障害」のまま残ってしまいます。そういうものだと全員が認識して運用できるならそれでもいいんですが、障害対応が終わったのに状態が「障害」で残っているのが気持ち悪いとか、勘違いするとか、そういった理由から、なんとか状態を正常に戻したい、という要求も出てくるわけです。
それの解決法の一つとして、一定時間該当するログが出ていなければ回復とみなす、そのために nodata を使う、という方法があったのです。

3.2 からはトリガーの状態を手動で回復させることもできるようになったため必ずしも nodata を使う必要はなくなりましたが、自動で回復させたいなどの理由で nodata を使う場面も残っているのです。

そして、「一定時間該当のログが出ていない」ことを確認するために regexp(条件,時間) を使おうとしても、その判定が開始されるのはアイテムが値を取得したタイミング、つまり「何かしらのログを受け取ったとき」であり、ログを受け取っていない間はトリガー判定すらされない（つまり回復もしない）、という話です。

トリガーの条件式に nodata などの時間ベースの関数が含まれている場合は、値取得のタイミングだけでなく定期的（30秒おき）にもトリガーの判定が行われるようになるため、ログを受け取っていなくてもトリガー判定が発生し、自動で回復させられるのです。

前の投稿で書いたのはそういう場面で nodata を使う話だと思って書いたものです。

逆に言うと、それ以外の場面で nodata なり regexp(条件,時間) なりを使いたい場面が思い浮かばないのですが、どういう場面を想定してらっしゃいますか？

2 については、3.2 以降であれば正規表現も使えるようになっていますよ（演算子に regexp を使う）。
https://www.zabbix.com/documentation/3.2/manual/appendix/triggers/functions
それより古いものだと、ぱっと思い浮かびません。

少々古い 2.2 のマニュアルですが、この挙動自体は今でも変わってないはず。
https://www.zabbix.com/documentation/2.2/jp/manual/config/triggers

＞トリガーステータス（条件式）は、Zabbixサーバが条件式中の値が新しい値に更新される度に、再計算されます。
＞条件式に時間ベースの関数(nodata、date、dayofmonth、dayofweek、time、now)が使われる場合には、
＞トリガーはZabbixタイマープロセスによって、30秒ごとに再計算されます。時間ベースまたは
＞時間ベース以外の関数が条件式に使用される場合には、新しい値を受信した時と30秒ごとに再計算されます。