State management has (had) a purpose. It allows you to do things like going backwards and forwards throughout the history of the state, convenient for instances where you need some kind of undo functionality
That covers only a tiny part of state management and is more like a convenient side effect of state management solutions like Redux. Depending on the Redux implementation you even need to opt in to keep history and it's often only used for debugging purposes but disabled in release builds.
The main issue is in my opinion, that most frontend developers see an application as a bunch of pages and forms that contain the functionality of the application and they somehow need to communicate a bit.
That's not a very sophisticated view of how to build applications.
If you use an architecture like en.wikipedia.org/wiki/Hexagonal_ar... (or jeffreypalermo.com/2008/07/the-oni...) then you'll see that the Application (core) is independent of the UI. That's quite the opposite of how most client applications are built nowadays, but not because it's better, but because most client applications are built by beginners.
If you use such an architecture you need quite a different point of view.
The application could be driven by a script, or seen as an API, or could have different views like one for mobile, browser, desktop, ... . The application could even be built without making such a decision beforehand. That usually won't be the case though, but thinking this way guides towards a better way of thinking about building applications.
It's also possible to render the same data in different ways in the same application without synchronizing the data between views, because the application holds the state only once an every view is based on the same data. The data changes, all views based on it change at once.
This way the whole application can easily be tested without any UI framework being involved.
All the view (UI) then does is rendering the data that was pushed from the application, and notify the application about user actions the application cares about (button clicked, item selected, ...)
If you use Redux as state management, the whole application is implemented in Redux' actions, effects, and reducers.
Redux also decouples side effects which often are async from pure functions which makes all code that's not side effects much simpler.
Building an application following an architecture like Hexagonal or Onion helps to avoid the tangled mess most client applications are today.
That Redux has often a bad reputation is because most people try to force their primitive approach of building applications onto it and then Redux only gets in the way and development mostly becomes a fight against Redux.
This is what in my experience leads to exactly the opinion about Redux you explained in your article.
So basically the whole article is an explanation how developers (you are not alone here, not at all) see state management before they started getting a basic understanding of software architecture.
Following better architecture patterns is hard to learn, but not because it's a difficult topic, but because the web is flooded with misguided instructions (like this article) but also like the Angular docs or Flutter docs (these I worked with most) and probably most others out there.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That covers only a tiny part of state management and is more like a convenient side effect of state management solutions like Redux. Depending on the Redux implementation you even need to opt in to keep history and it's often only used for debugging purposes but disabled in release builds.
The main issue is in my opinion, that most frontend developers see an application as a bunch of pages and forms that contain the functionality of the application and they somehow need to communicate a bit.
That's not a very sophisticated view of how to build applications.
If you use an architecture like en.wikipedia.org/wiki/Hexagonal_ar... (or jeffreypalermo.com/2008/07/the-oni...) then you'll see that the Application (core) is independent of the UI. That's quite the opposite of how most client applications are built nowadays, but not because it's better, but because most client applications are built by beginners.
If you use such an architecture you need quite a different point of view.
The application could be driven by a script, or seen as an API, or could have different views like one for mobile, browser, desktop, ... . The application could even be built without making such a decision beforehand. That usually won't be the case though, but thinking this way guides towards a better way of thinking about building applications.
It's also possible to render the same data in different ways in the same application without synchronizing the data between views, because the application holds the state only once an every view is based on the same data. The data changes, all views based on it change at once.
This way the whole application can easily be tested without any UI framework being involved.
All the view (UI) then does is rendering the data that was pushed from the application, and notify the application about user actions the application cares about (button clicked, item selected, ...)
If you use Redux as state management, the whole application is implemented in Redux' actions, effects, and reducers.
Redux also decouples side effects which often are async from pure functions which makes all code that's not side effects much simpler.
Building an application following an architecture like Hexagonal or Onion helps to avoid the tangled mess most client applications are today.
That Redux has often a bad reputation is because most people try to force their primitive approach of building applications onto it and then Redux only gets in the way and development mostly becomes a fight against Redux.
This is what in my experience leads to exactly the opinion about Redux you explained in your article.
So basically the whole article is an explanation how developers (you are not alone here, not at all) see state management before they started getting a basic understanding of software architecture.
Following better architecture patterns is hard to learn, but not because it's a difficult topic, but because the web is flooded with misguided instructions (like this article) but also like the Angular docs or Flutter docs (these I worked with most) and probably most others out there.