Yes you could edit the database properties ^DATABASE so a particular database did not journal but I would be worried that the journals will also change the other datasets so I would unmount them before applying journals.

It might be better to create a parallel instance and mount the restored database and then replay the journals.

For a production issue I would reach out to the WRC.

The host, storage and DB engine don't influence the gref count at all. Only what the code does.
If you do a set,kill or write that is a gref.
The host, storage and DB engine determine the limit of grefs per second.
Faster storage is always better.
More memory (larger global/routine buffer) is always better.
Faster cores are always better. More cores are better if there is work for them to do.
Newer versions of IRIS (DB engine) are always better.

GLOSTAT will give you some numbers

Vertical Scaling IRIS

One thing you can do is run it in steps for both the compaction and the free so you have performance effect data on your actual system. Do a run to compact and free of maybe 1 or 10 Gb.

Be ready for the WIJ to expand.

Try it on a non production copy if you can first and run an Integchk on the dataset after.

Make sure you are on a current version of Cache or IRIS since some versions had issues.

Know when your system really has it low utilization period. You might have midnight/end of day processing or someone might do the weekly ETL on the weekend.

Intersystems has worked hard but encryption is not free. Do you have something like batch processing? You would notice an impact more there then on a 1 second query. I would worry more about key security and recovery. Encryption also has a serious impact on the ability of modern SAN storage to dedup and compress which could result in higher than expected storage costs.