Should I wrap every prop with useCallback or useMemo, when to use this hooks?

Not worth it, for multiple reasons:

1. Even official docs say you should do it only when necessary.
2. Keep in mind that premature optimization is the root of all evil :)
3. It makes DX (developer experience) far worse: it's harder to read; harder to write; harder to refactor.
4. When dealing with primitives (like in your example) memoizing costs more CPU power than not doing it. A primitive value doesn't have a concept of references, so there's nothing to memoize in them. On the other hand, memoization itself (as any other hook) does require some tiny processing, nothing is for free. Even though it's tiny, it's still more than nothing (compared to just passing a primitive through), so you'd shoot your own foot with this approach.

To put all together - you'd waste more time typing all the hooks than a user would gain on having them in the application if you want to put them everywhere. The good old rule applies: Measure, then optimize.

I agree with the principles proposed by @jalooc

To give some more insight about the exhibited use cases in the OP, here is my advice:

Expensive children renders

function Component() {
  const callback = useCallback(() => { dostuff }, [deps])

  return <Child prop={callback} />
}

The above makes sense if Child is a very expensive component to render. As such, it is probably exported like so:

function Child() { 
   ...this takes significant CPU... 
}

// Export as a pure component
export default React.memo(Child)

Expensive computations

function Component({ foo }) {
  // This very expensive computation will only run when it's input (foo)
  // changes, allowing Component to re-render without performance issues
  const bar = useMemo(() => {
     ... something very complicated with `foo` ...
  }, [foo])

  return <div>{bar}</div>
}

Conclusion

1. Do what makes sense or that have measured bad performance
2. A function declaration inside a component changes at each render. If this causes derived expensive computations, memoize it (useCallback) or move it outside the scope.
3. If a component itself is expensive to render, make it pure with React.memo, with the help of #2 if necessary
4. If something IS itself expensive to re-compute, memoize it (useMemo)
5. Do what makes sense or that have measured bad performance

I'd argue that there's nothing wrong with putting useCallback everywhere you create a function. The same points are applicable to useMemo; but I'll be mentioning only useCallback since, for the sake of brevity.

As a concession, I must mention that this isn't a cornerstone in your development process, and you must proceed with a solution that your team is comfortable with, whether it's using useCallback or not.

My main argument for using such memoization hooks "extensively" is that you don't have to think of potential performance issues on the front of "reference update-induced" rerendering if you do it. Fewer things to think about = good. More time and energy to solve the actual problems.

Many say "premature optimization is bad". Well, cargo cult isn't good either, and this citation is a pure example of such, taken too far out of context, and with a premise of having an authority behind it. here used to be a good summary on that, unfortunately, the account is taken down currently, but it's available on archive.org.

The concerns of "premature optimization" in this case are structural changes to the code and impaired readability/write-ability.

Structurally, these changes are for the better, making you separate your components.

Readability-wise, there's an extra wrapper, but that comes together with strict tracking of your function dependencies, which otherwise is done implicitly. Dependencies become explicit as they should be since in this system they play a too important role to swipe it under the rug. Readability, therefore, only wins. Although it's harder to write now, the "ritual" is always the same. Readability is more important than the convenience of writing a function. (Just make sure you use eslint to track your dependencies; it could be a headache when you forget to add a dependency and it gets cached.)

So, "write now, optimize later" - thanks, I'd pass. To me, it's a negligibly cheap optimization that is justified enough and is reasonable enough, if your team is ready to accept the arguments above. It's also fine if they aren't: the topic itself isn't something to die for. It's just a small quality-of-life tool.