Solid benchmark — the stream pipelining section is particularly valuable since that behavior isn't obvious from the docs alone and most teams wouldn't think to grep driver logs to confirm it.

One dimension worth adding to the decision table: the cost break-even point. The table notes that triggered mode "avoids unnecessary active execution cost during idle periods," which is correct — but the comparison isn't symmetric. Continuous mode pays for steady-state compute even when no data is arriving; triggered mode pays startup overhead (153–194 seconds per invocation in your benchmark) on every cycle regardless of data volume.

The math shifts with arrival rate. At low throughput (sparse events, long quiet windows), triggered on a 5-minute schedule means startup overhead is a fixed tax on a small data payload, but the pipeline is idle 70%+ of the time — triggered wins on cost. At high continuous throughput, continuous mode's steady-state efficiency closes the cost gap quickly, especially once stream pipelining kicks in and utilizes those otherwise-idle CPU cycles.

A hybrid pattern that works well in practice: Bronze/Silver on continuous to meet the freshness SLO, Gold/reporting layers on triggered at 15–30 minute intervals. Gold is typically aggregation-heavy and latency-tolerant — no user is waiting sub-minute for a daily revenue roll-up. You preserve the freshness guarantee where it matters and avoid paying continuous compute hours on your widest, most expensive tables.

The pipelines.trigger.interval per-table config you mention at the end enables exactly this within a single pipeline — worth calling out explicitly as the primary lever for this hybrid approach.