The main point of this is to make container components as “dumb” as possible and to isolate it from business logic which makes them easier to test and easier to divide work between multiple developers.
If you use action creators as commands, your component still has to be aware of its environment and decide what should happen next.
Then, if in the future you need to change this behaviour, you need to update all container components that affect this change (often across multiple teams).
Using events is most beneficial when doing side effects, and the example of “infinite scroll view” described in “Other benefits” originates from “redux-saga” examples (by the way redux-saga docs is a good place to learn more about this).
But even if your action has no side-effects, you never know if UNDO will always be synchronous and what requirements will it have to support.
By using granular events describing facts, you can use process-manager to handle all this logic which is also great for other people to see what your app is doing.
Again, all of this is probably an overkill for simple apps.