The React docs give some example use cases for context:
Context is designed to share data that can be considered “global” for a tree of React components, such as the current authenticated user, theme, or preferred language.
The common property of these use cases is that data like the current theme doesn't change often and needs to be shared deep down the component tree, which would be cumbersome with "prop drilling". Something else that needs to be shared everywhere is the application state when using a "single source of truth" pattern, so it would follow that the context API would help with that as well, but there's a catch: components that use context will rerender every time that the provided value changes, so sharing the whole application state through context would cause excessive render lifecycles.
The answer to when to use and not to use context is clear and simple, but somehow it's still common to compare context to Redux, which manages state as a single source of truth. A quick survey of search results about this topic confirms that some resources just haven't come to grips with the limits of context, but that's to be expected, because the almost two years that the context API has been around isn't that long considering the rate of JavaScript churn that developers have to keep up with. A more interesting observation is that a common thread is a demand for a more lightweight alternative to Redux, and context with useReducer() superficially seems like it could fill that role. Enter Redux Toolkit.
Even the Redux FAQ comes with a strong caveat about the boilerplate (although placed in scare quotes) and developer overhead of using Redux, and related libraries like reselect and Immutable.js up the ante even more. At the same time, even weighed against the complexity, the benefits of Redux and the Flux pattern have been enough that Redux has significant community traction and an ecosystem of tools, including ones as nice as the Redux DevTools. Redux isn't something that can be easily written off as a bandwagon.
There have been a string of alternative state management libraries to simplify the boilerplate while using the same pattern as Redux, and Immer in particular has been a boon for this, but they largely haven't managed to reach maturity or to integrate with the existing tooling. Redux Toolkit changes this in that it's still Redux, has official approbation, the Redux DevTools and various Redux middleware still work, and it solves the boilerplate of defining and using actions, reducers, stores, etc., and of immutable updates (courtesy of Immer).
Redux Toolkit changes the calculation about when Redux should be used, making it sensible to just use Redux Toolkit by default in "greenfield" projects, even in simpler ones. Redux Toolkit doesn't offer anything special for async modeling like sagas, but redux-thunk is fine.
Not everything can or should be put in a Redux store, and in particular it can't hold objects that can't be serialized, so that may be a use case for the context API if it helps avoid prop drilling (although it's a good idea to consider component composition first).
Reddit discussion.