Why we need to use NSPersistentHistoryTransaction if NSFetchedResultController able to update UI correctly?

I still fail to understand, what is the problem NSPersistentHistoryTransaction is trying to solve, in the CoreDataCloudKitDemo WWDC 2019 "Using Core Data with CloudKit"

https://github.com/software123inc/CoreDataCloudKitDemo/blob/master/CoreDataCloudKitDemo/DataProvider/CoreDataStack.swift#L161

I want to see, what problem will occur, if processPersistentHistory is not executed.

By making the processPersistentHistory empty, I try to do the following testing.

1. Run 2 simulators simultaneously in the same machine.
2. Add an item to simulator A.
3. Since, there is no way for simulator B to receive push notification, I press the home button for simulator B.
4. In simulator B, I tap on the app icon to launch the app again.
5. In simulator B, I can observe controllerDidChangeContent is being called. My guess is that, because the backed SQLite is seamlessly updated by CloudKit background task, NSFetchedResultController will be notified the SQLite DB change, and subsequently update the UI. Check the "Download CloudKit Changes into Core Data" of https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/syncing_a_core_data_store_with_cloudkit
6. In simulator B, due to controllerDidChangeContent is being triggered correctly, I can observe the UI change perform by NSFetchResultController without issue.

Hence, I am not clear, on what problem processPersistentHistory is trying to solve in the demo code.

May I know what kind of test case I can perform, to understand the problem solved by processPersistentHistory?

Based on "Integrate Store Changes Relevant to the Current View"

https://developer.apple.com/documentation/coredata/mirroring_a_core_data_store_with_cloudkit/syncing_a_core_data_store_with_cloudkit

Your app receives remote change notifications when the local store updates from CloudKit. However, it’s unnecessary to update your UI in response to every notification, because some changes may not be relevant to the current view.

Analyze the persistent history to determine whether the changes are relevant to the current view before consuming them in the user interface. Inspect the details of each transaction, such as the entity name, its updated properties, and the type of change, to decide whether to act.

For more information about persistent history tracking, see Consuming Relevant Store Changes.

This part is getting confusing. Our NSFetchedResultController is receiving relevant entity change event due to SQLite, and subsequently able to update the UI correct. If that is so, why do we still need persistent history?