Why is a projection's read model table considered disposable, and what practical benefit does that give a team?

A read model table has no direct relationship to the event store — it's an ordinary table holding no data that doesn't already exist, in a different shape, inside the event history. Because it's populated entirely by a projection's @EventHandler methods reacting to events, it can be dropped completely and perfectly rebuilt by replaying every past event for the relevant aggregates back through that same projection. Practically, this makes evolving read patterns low-risk: a team can add a brand-new projection to support a new feature, run one replay of the historical event stream to backfill it, and have it immediately caught up, with no changes needed anywhere on the write side. It also means a projection that's drifted out of sync due to a bug can be repaired by rebuilding it from the event store, rather than requiring manual data correction.