There can be scenarios which has resulted in the glide.db.archiving.max_consumer_workers property has set to a value other than 4.
Out of the box the property does not exist; in which case the platform will assume a default value of 4.
In the cases where the glide.db.archiving.max_consumer_workers is set to a different value, this can be ignored UNLESS your archiving process is not keeping up with the records that need to be archived. If you are running with a reduced number of consumer workers (ie property value is less than 4) and your archiving is falling behind, this warrants a review.
Paris Family +
Usually, the property would have been changed by recommendation from ServiceNow due to database replication lag. This is often a temporary measure to allow the data replication to catch up and sometimes the value is not reverted back to out of the box once the replication has caught up.
So the property can be changed back but with caution and due diligence.
If your archiving is keeping up, then no action is required. If you want to increase the 'concurrrent' archiving throughput and the glide.db.archiving.max_consumer_workers property is < 4, the recommendation is to nudge the value up incrementally to a maximum limit of 4. If there are NO performance issues on the instance, you can keep nudging the value until you reach 4.