I don't think this is going to (solely) related to commit point optimisation, but more that GoldenGate is not going to see batched deletes as "batches" because the redo stream is not going to reflect that.
A single delete removing 1000 records will yield 1000 redo records each being a "delete row", which is how they will be manifested at the target node.
You could explore the BATCHSQL mode to see if this helps.
https://docs.oracle.com/en/middleware/goldengate/core/12.3.0.1/gwurf/batchsql.html#GUID-2ED88418-6ACB-484D-B140-364232EC419A or perhaps isolate this table(s) into its own group so that its replication latency doesn't create system wide latency.
Historically, a common technique for large batch operations was to temporarily halt GG, apply the batch on both source and target, and then resume GG. MOS note 1451675.1 has some information and controlling structures around that process.