Replication testing is a Materialized view Refresh equivalent of continious update?
For most practical purposes, UPDATE is pretty much the same as DELETE + INSERT in PostgreSQL. The difference between your tests is that test1 refreshes the materialized view twice and runs one more VACUUM.

Refreshing a materialized view is something entirely different. It will effectively drop the materialized view and re-create it from scratch. If you use REFRESH MATERIALIZED VIEW CONCURRENTLY, you will see activity similar to INSERT and DELETE.


max_standby_archive_delay does not apply to streaming replication at all.
max_standby_streaming_delay governs if there will be a delay in applying data changes on the standby server in the case of replication conflicts.

Both your tests will eventually generate replication conflicts as soon as autovacuum removes old row versions from a_table or b_table, but only if hot_standby_feedback = off. If hot_standby_feedback = on, you will not see a replication conflict until a random autovacuum run truncates empty pages off the end of one of the tables, which requires a short ACCESS EXCLUSIVE lock.

You could reliably trigger a replication conflict by selecting from the materialized view on the standby while it is being refreshed on the primary, because that takes an ACCESS EXCLUSIVE lock on the materialized view.
hot_standby_feedback: If set to on, then if either of your tests runs long enough while the query on the standby is running, you will slowly see the tables grow and get bloated, because old row versions won't get removed on the primary.

If set to off you will get replication conflicts as soon as one of the tables is vacuumed.