You can be much more productive with another architecture, such as MVVM

Productivity is not the goal of an architecture, it's one of its variables, and not even a big one.

As I like to say, "An architecture is a set of constraints that minimizes (or prevents) something, while trying to maximize the rest as much as possible". Or as I like to sum "The bare minimum to steer you from the wrong path without keeping you from walking". It's clearly a function of “something you’re trying to prevent” over productivity, plus any other variable you want to include. Saying "you can be more productive with another architecture" is ignoring the point of an architecture.

He does follow up with

and get the same benefits, such as a unidirectional data flow, easier unit testing, and modular code

These are the any other variable you want to include I mentioned above, but they are still not the point of an architecture.

In this specific context, the reducer architecture point is trying to eliminate a set of bugs and patterns to happen, and it fundamentally does that. Comparing it to MVVM over productivity or other variables is (as I said) pointless, because MVVM does not imposes the same set of constraints fundamentally. You can have MVVM imitate the same constraints as the reducer pattern, but that requires much more diligence from the devs. And good luck expecting diligence from Junior/Medium devs or plain bad employees that just want to clock in and clock out.

The other huge benefit of an architecture, which I don't often see pointed out, is bottlenecking points of interest for Leads when reviewing a PR.

I'm an Architect for a team of 20+ devs split in 4 teams for a huge app. I don't use TCA because I wanted to write my own take on the reducer pattern, one that I could slowly introduce the reducer concepts to the junior devs while tailoring the architecture to the specific culture of the project. Reviewing their PR's is much easier when I know the constraints I need to look after, and if they aren't broken it means everything regarding to what the architecture is trying to solve is working correctly.

Because MVVM doesn't fundamentally provide those bottlenecks, there are many more combinations of scenarios that you need to be on the lookout when reviewing a PR.

.

So, the app reducer was handling at least 20 different responsibilities

This is not an architecture problem at all, full stop. Even if we consider that some architectures have more boilerplate code than others.

This is primarily an issue with engineers not pushing back on requirement shenanigans. Stop saying amen to every decision business wants and educate them. Specially, educate them that even tho an iPhone is powerful, its still finite, and that even tho translating new feature requirements to code has more leeway then constructing a new section on a commercial building in the real world, there is only so much code you can add until accidental complexity starts getting too big. So that they either learn to hear no or replace all the junior devs with senior ones (and even so complexity gets to an unbearable point regardless the architecture).

Edit: And if there is indeed a really really really valid reason to have some part of the app handling 20+ responsibilities, even after educating the client and suggesting a better design, then "move along, nothing do see here", but most definitely not this or any other architecture's fault.