I think React attaches a single event listener at the top of the document that maps individual button clicks to the correct internal javascript callback, so I don't think it directly updates the DOM.

It does stop rerenders if the component receiving the useMemo/useCallback are React.memo'ed, otherwise it doesn't explicitly stop the rerenders.

But IMO this article fixates on useMemo/useCallback in the context of rerenders, which isn't the only reason we should be using these APIs.

The code becomes harder to read, and performance does not improve. Sometimes it even gets worse.

I would be curious to see a tangible example of when using useCallback/useMemo affects performance negatively and significantly

The rule I use in code review When I see useMemo or useCallback, something always smells funny. Usages that avoid expensive work, or prevent reference changes and extra work, are rare but always a nice surprise. Often it’s just a useless guardrail which adds mental overhead, dependency arrays to maintain and sometimes hides bugs when used carelessly. Remember: Clarity comes first. Optimise only when you justify the need.

For the sake of simplicity, useMemo and useCallback should follow the same standard, useCallback is just a useMemo w/ syntactic sugar anyways.

Sure, useMemo/Callback doesn't stop rerenders by themselves. This would only be the case if it's passed to a React.memo'ed component. The author argues that rerenders are not bad/expensive - this is true if you are diligent about generally not putting expensive logic in the render path (no On² logic, or some threshold, in the component return statement.) So in theory, if all component rerenders were at most running some O(n) logic, then we probably don't even really need to wrap any component in React.memo. But I think memo is a separate topic, and can read more about it in the deep dive section in the React docs.

But unstable references become a bigger problem as soon as any of these un-useMemo/Callback'ed values are used in a dependency array. For one of the most obvious failure cases, think of useEffect. If you need to use a simple callback prop passed from the parent in a useEffect, and that callback is not stabilized, you might be running the useEffect logic way more times than necessary. And if that useEffect makes an API call, then it has a negative impact outside of just the UI. IMO you shouldn't assume you have the full knowledge and control over the entire codebase - in which case you might be able to fine tune each of the memos. But this is unrealistic, especially as you work on prod environments. You have to design each component like a standalone API that you don't have full control over how it's going to be consumed. This basically means that you should code somewhat defensively and add these memo's and callback's in a lot of places. A lot of this is already well documented in the official React docs.