That would be a reasonable approach.
Rather than tomb-stoning archived streams it may be better to write a redirection record to the stream and set the max length to 1.
the scavenge will the pull most of the data out and the running application would know where the stream went. The redirection record may also keep simple data like a display name and archive data & link to allow the running application to display or find the record if needed.
The secondary event store(s) can also leverage lower tier storage, and/or in some cases be left cold and have only a single node spun up to read the data on demand. e.g. pervious years records that are truly read only for cold storage.
Another way to reduce the data in the Event Store is to apply some of the well know principles of 3rd and 1st NF data from classical db theory. when writing to streams keep the pricliples of 3rd NF data to heart. Data should only be written in one place and referenced by surrogate key links if needed (think Guid identifiers to related streams or aggregates closer to a pointer reference than a forgien key in practice, but nearly identical in function. n.b. any FK constraints would be enforced in the aggregate code rather than the db.)
Then when dealing with read models think about them as following a 1st NF style. They are the materielized views, cache objects, or reporting tables that are produced for the system to read. here they pull all of the data together into a targeted view for the application to process. This allow the application to not worry about the equivalent of complex joins rather that handled by the event processors that build the views/read models.
Quite often when I see large data sets in steams it is due to the instinctive reaction to place data in the events for the view or to repeat unchanged data in the update into the stream. The concerns for pulling data together for the view should be solely the job of the read model builders, and they will have the benefit of the current state right there in the target they are updating.
One case where events will have repeated data is when they are public events to be published externally. These are just a different type of read model and should follow the 1st NF style.