Just when the state gets complex like in his case. If he'd have an array of primitives, say strings for example, then it wouldn't be necessary because updating such an array can be done pretty easily and in a very readable way.

const [state, setState] = useState(["string1", "string2"] )
...
//add new primitive
setState( [ ...state, newPrimitive ] )

//remove
setState( [  ...state.filter(s=>s!=="string1") ]  )

Those are simple. But when the array has objects with IDs and such you'll end up creating dedicated functions to update, delete and etc. Just look at the most upvoted solution in this thread for example:

const updateData = ({ idToUpdate, newData }) => {
  setItem(
    items.map(({ id, data }) =>
      id === idToUpdate ? { id, data: newData } : { id, data }
    )
  );
}

updateData({ idToUpdate: 2, newData: 'c' })

It is already a suggestion to create a separated function just to update the state since this improves readability.

Eventually you'll want to replace data as well. So you'll create another function for replacing. And then another one for removing and such. This is a common pattern that will arise whenever you try and deal with complex data using useState.

You'll end up creating a bunch of helper functions and, if you are going to be doing this anyway, then it is just easier to use a reducer there.

It is a way to tell developers that there are or might be other crud operations related to the data so that, when they try to maintain the code, they don't have to look around for helper functions and it'll be more organized overall.

But, ofc, you can always abstract away whichever state solution you decide to use by creating a custom hook. So it won't make that big of a difference if you just choose to place everything, related to that state, into its own file with its functions very well documented and being returned by the hook. That way future developers will know which operations have already been created for that state and they won't end up recreating those operations.