That makes sense.
Both of these components (for the most part) shouldn’t really need to scale at all and benefit from having PubSub pull semantics rather than having to revert to push. The mutator itself is only performing occasional, depending on how often you update schemas, DDL operations so can run on a very small VM instance. The repeater will be inserting data, but typically only data that couldn’t be sunk to BigQuery in the first instance (mostly due to mutation lag).
Although you could move this to Cloud Run it’d be a significant refactor and you would take a performance hit as CR would need to process each message individually (could be a problem for the mutator from a state point of view, and the repeater from a latency point of view). Due to the concurrency limits around Cloud Run you would end up with a solution that would likely need more configuring than an equivalent always on VM.