¿Cómo decides dónde debe vivir una pieza concreta de estado?

Empieza lo más local posible, dentro del componente que lo usa, y súbelo solo al ancestro común más cercano cuando los hermanos de verdad necesiten compartirlo. Si son datos del servidor, van en una capa de datos con caché, no en el estado del componente. Si el usuario debería poder enlazarlo, como los filtros o la pestaña actual, ponlo en la URL. Un store global es el último recurso.

Mi primer movimiento es averiguar qué tipo de estado es, porque la mayoría de las cosas que la gente llama estado no son estado local de verdad. Si vino del servidor, va a una caché de queries, así que obtengo deduplicación, revalidación y gestión de datos caducados en vez de montármelo a mano con useState y un efecto. Si debe sobrevivir a un refresco o poder compartirse como enlace, como los filtros activos o qué pestaña está abierta, va en la URL. Lo que queda es estado de UI genuino, y eso empieza en el componente que lo usa. Solo lo subo cuando un segundo componente lo necesita de verdad, y entonces solo hasta el padre común más cercano. Los stores globales los reservo para cosas realmente transversales, como el usuario actual o una conexión websocket. El fallo que más veces he tenido que limpiar es estado que se subió a un provider de nivel superior porque dos componentes lo necesitaron una vez, y dos años después todo se re-renderiza con cada tecla y nadie se atreve a devolverlo abajo.