If you look at your option 3 there is room to expand to make it more cost efficient with lower latency.

Run GBQ aggregations once every 30 minutes. This works, but I wonder
if I can achieve better cost efficiency and latency with other
solutions.

In this scenario you would end up with 3 objects, 2 tables and one view.

Table_A can serve as your raw data, no deduping just straight inserts off the pubsub subscription. This table is partitioned by either ingestion time or another timestamp relative to the message.

Table_B is aggregated nightly and handles the deduplication process of the previous days data with a MERGE.

View_C unions both table_b and the latest day of partition of table_a that is deduplicated on the fly. Then using a set operator like UNION or INTERSECT DISTINCT you would get a deduplicated dataset with low latency and a lower cost footprint than running the aggregation every 30 m.

Loosely your view would look something like this:

select distinct * 
from table_a 
where PARTITION_COLUMN = CURRENT_DATE() {UNION DISTINCT | INTERSECT DISTINCT}
select * from table_b

example diagram

This would be very low latency as once data is written it is available in the view. From a cost perspective you would be minimizing the logic and processing required as well as being able to get rid of the VM to publish data and the second pubsub topic.

EDIT:
Adding link from comments to similar use case for CDC streaming that has a similar solution and explanation of the approach.

https://cloud.google.com/architecture/database-replication-to-bigquery-using-change-data-capture#query_the_data