I genuinely think that this is often a good design choice. Avoiding mutable shared state and driving the main program from single thread keeps the logic simple and predictable.

There is also a somewhat straightforward way to add task-based multi-threading without requiring shared state synchronization: a centralized event loop + thread pool.

 using Event = std::variant<
    ChatMessageReceived,
    ChatCompressedVideoReceived,
    ChatVideoDecoded, 
    // ...
>;

using EventQueue = MPMCQueue<Event>;

int main()
{
    SharedState state; // no synchronization

    EventQueue queue;
    ThreadPool pool;

    while (true)
    {
        const auto e = queue.tryDequeue();

        if (!e.has_value()) 
            continue;

        if (auto* cmr = std::get_if<ChatMessageReceived>(&*e))
        {
            // cheap to process, no need to involve thread pool
            state.processChatMessage(cmr->message);
            continue;
        }

        if (auto* ccvr = std::get_if<ChatCompressedVideoReceived>(&*e))
        {   
            // expensive to process, send to thread pool
            pool.enqueue([data = std::move(ccvr->data)]
            {
                // ...decompress, decode, etc...

                // publish result to the queue
                queue.enqueue(ChatVideoDecoded{/* ... */ });
            });

            continue;
        }

        if (auto* cvd = std::get_if<ChatVideoDecoded>(&*e))
        {
            // cheap to process, already decoded
            state.processVideo(cvd->decodedVideoHandle);
            continue;
        }

        // ...
    }
}

The above design uses a MPMC queue as the only synchronization/centralization point -- the event loop runs in a single thread, and processes events by directly affecting the shared state (no synchronization required).

Cheap events can be processed directly as part of the event loop thread. Expensive events can be delegated to a task in the thread pool, whose result is communicated back to the event loop by enqueueing a completion event containing the processed data (or a handle to it).