これはまた難儀なログ監視をしていますね。。。
求めている監視条件定義をもっと詳しく知りたいですが、内容を推測した上でいくつか施策を考えてみました。
考慮すべきポイントが幾つかありますので、参考になればと思います。

■トリガー定義
下記のように番号を振らせていただきます。またトリガーの発動条件を明確にするためトリガーの発動条件を記載します。

①{Template Template:logrt[/var/log/dir/^system\.(log|log\.1)$,ERROR].iregexp(".*Serial read Error:errno.*",300)}<>0
⇒「ERROR」が含まれる「/var/log/dir/^system\.(log|log\.1)$」に、300秒間(※)文字列「.*Serial read Error:errno.*」がマッチしたら検知。
※どこ基準に300秒間？　iregexpに時間指定しているものを見たことがないので挙動が分からない。。。

②{Template Template:difftime[].last()}>0
⇒difftime[]の最新値が0より大きい場合に検知。

③{Template Template:difftime[].last()}<=600
⇒difftime[]の最新値が600以下の場合に検知。

④{Template Template:logrt[/var/log/dir/^system\.(log|log\.1)$,ERROR].nodata(300)}=0
⇒「ERROR」が含まれる「/var/log/dir/^system\.(log|log\.1)$」に300秒間データが無い場合は「正常」(※)
※逆に言えば、「/var/log/dir/^system\.(log|log\.1)$」に300秒間以内の間隔で継続的に「ERROR」がログ出力され続けると、
　トリガーが「障害」状態のまま復旧しなくなる。復旧していないので、再度障害が発生してもアラート検知せず障害に気づけない危険性がある。

■①と④の修正（nodataの発動条件の整理したい）
提示されている監視トリガーですが、①と④で「障害」フラグの発動条件が被っている？ようにも思えます。
大量検知を予防するためのnodataだと思いますが、nodataはログ監視では不規則な動作を取ることが多いので、
発動条件をもっと限定的に整理したほうが良いと思います。少し大幅な変更点がありますが、私なりの修正案を提示しようかと思います。
※考え方が思っているような方向とズレている場合はすみません。。。
===========================================================================================
【修正案】
①{Template Template:logrt[/var/log/dir/^system\.(log|log\.1)$,@ERROR_Serial].count(300,"Serial")}>0
「@ERROR_Serial」が含まれる「/var/log/dir/^system\.(log|log\.1)$」に、300秒間で「Serial」が0件より多く出力されたら検知。

④{Template Template:logrt[/var/log/dir/^system\.(log|log\.1)$,@ERROR_Serial].nodata(300)}=0
「@ERROR_Serial」が含まれる「/var/log/dir/^system\.(log|log\.1)$」に、300秒間データが無い場合は「正常」にする。

「@ERROR_Serial」を新規正規表現として定義、「ERROR」に追加で「.*Serial read Error:errno.*」が真を設定。
⇒「nodata」の挙動を「.*Serial read Error:errno.*」が出力されるパターンに限定させたい。
===========================================================================================

■並列and条件を修正
現状ですと、and条件が並列化されており、「A and B and C and D」となっているため障害フラグがどこで立つのかかなり怪しいと感じます。
下記のように()でand条件を縛って、障害フラグを管理したいと感じます。
===========================================================================================
【修正案】
({Template Template:logrt[/var/log/dir/^system\.(log|log\.1)$,@ERROR_Serial].count(300,"Serial")}>0 and
({Template Template:difftime[].last()}>0 and {Template Template:difftime[].last()}<=600)) and
{Template Template:logrt[/var/log/dir/^system\.(log|log\.1)$,@ERROR_Serial].nodata(300)}=0

⇒「(A and (B and C)) and D」にトリガー発動条件を変更。
===========================================================================================

■イベントが06:10頃から07:20まで障害⇄復旧を繰り返す原因
これは恐らくですが、下記が原因で発生しています。
①監視対象の「Agentは毎日06:00頃起動し、16:00頃にシャットダウンする」こと
②「difftime[].last()」が「0」で復旧判定している
③「nodata」&「障害イベントを継続して生成：しない」でトリガー判定が60秒スパンにされている
④「nodata」が「障害」判定フラグを維持しようとしている

Agentが6:00頃起動し、短時間に夜間中のログ読み込みが発生するため、
そこから「.*Serial read Error:errno.*」をトリガーでマッチ判定し「障害」フラグを立てるのに10分程度要しているのかも知れません。
その後は、恐らく「difftime[].last()」が「0」で復旧判定になるため即時復旧。
「nodata」&「障害イベントを継続して生成：しない」で見たことがある動作(バグ？)なのですが、
トリガー判定が60秒スパンになる挙動を取ることがあります。そのため「障害」判定フラグが約1分後に立つのだと思われます。

また「nodata」は「障害」判定フラグを維持しようとする挙動を取ります。それが災いし、7:20まで継続するのかもしれません。

■その他考慮点
「/var/log/dir/^system\.(log|log\.1)$」がかなり気になっています。これはもしかしてですが、
「system.log」と「system.log.1」などが併存しており、どちらのログにも、同日内にログ出力があるという認識で正しいでしょうか？

もしそうだとすると、「system.log」にログ出力された後、「system.log.1」にログが出力されて、
そしてまた「system.log」にログ出力されると、Zabbixは「system.log」を最初からすべて読み直してしまいますが大丈夫でしょうか。
そうなると過去ログを再取得し、アラートを無意味に検知してしまうことになるので、挙動的にとても良くないです。複数のログを1つのアイテムに格納するべきではないです。

以上なので、参考になればと思います。