Regarding its suggestions, I try to comment on them one by one:

Performance Bottlenecks Analysis

Sequential Action Processing: At the moment I think it doesn't justify the complexity it brings, at the moment the core of the store has a very simple single-threaded logic, it runs side-effects and autoruns in other threads with the assumption that those are time consuming stuff and the reducers are very cheap to run. I think with well-implemented reducers, it shouldn't become a bottleneck in the future.
Listener Notification Overhead: It's a good idea to run listeners using a thread pool.
Event Handler Queue Bottleneck: I think the queue data-structure is optimized for this exact purpose of queueing tasks/messages for worker threads.
Memory Allocation for Immutable State: The information should be buffered somewhere and dispatched, and this process needs memory by its nature. I think it can't be changed in an action-dispatching store.

Data-transfer bandwidth considerations:

State Serialization: It is not something happening all the time in runtime, it only happens in tests and when writing to filesystem, etc. It doesn't matter, in ubo we have a serialization mechanism for serializing/deserializing data to/from gRPC, it is done by betterproto and it's a repository with good reputation.
Event payload size: We have zero problem with this, the only limit here is the bandwidth of the underlying communication infrastructure. Note for ubo: gRPC is binary serialization and is super optimized for this purpose.
Worker thread communication: It's in memory, I don't think we have any concern here.

Suggestion: Benchmarks #3

Description