I would describe the reasons to useMemo or useCallback as follows, in order of decreasing importance: 1) referential equality of non-primitives (any object, function, etc.) passed downstream as props and 2) expensive computation. The first one is for me non-optional, and I’ll focus on that (as the second one is self-explanatory).

Once you know about the reactive render cycle, it becomes a second nature to never create any object other than via a memo function with declared dependencies. Anything else—any instance of something like <Component someProp={[1, 2, 3]} />—is, to me, just a bug on the caller side, not something to be accommodated.

Furthermore, ensuring referential equality has benefits beyond avoiding re-renders (which I would acknowledge should generally be harmless, although are in practice a source of hard to spot issues and loops on occasion).

— First, it serves as a clarity aid and documentation for yourself. It helps maintain a mental graph like “caller-provided props A and B are used to compute prop C for a downstream component”. Code organized this way tends to have self-evident refactor routes, and logic naturally localizes into cohesive sub-blocks with clearly defined inputs and outputs.

— Second, and it is obviously an ES runtime thing, but it is simply weird to have to reason about objects being essentially the same but different—and if memoization allows me to not have to do it and, with some discipline, make it safe to assume that (() => true) is the same as (() => true), why pass on that opportunity?

That said, now that I see an alternative take on this, I will make sure to document my approach in the development guidelines section of the README.