It's still 100% Redux. You create reducers, add them to a store, dispatch actions, and read that data in your components. None of that has changed. You're just writing less code to do it.
What RTK does is eliminate the "incidental complexity" that came along with the original Redux usage patterns: writing action types and action creators by hand, writing complex nested immutable update logic by hand, making a mistake in that immutable update logic and causing accidental mutations, etc [0].
I do understand the suggestion to "replace the Redux core with RTK", and I take it as a great compliment that people suggest that. However, it can't happen, because a lot of people are already using Redux with their own customizations and abstractions. Changing the Redux core to suddenly include a bunch of other dependencies would not be what they want.
The other aspect is that the Redux core was designed from the beginning to be unopinionated, while RTK is _deliberately_ opinionated. Not all Redux users want RTK's opinions. As it is, we've had folks who didn't like the fact that RTK _is_ opinionated and requires use of Immer in our `createReducer` and `createSlice` APIs.
We had a long discussion issue about whether it made sense to add things like this to the Redux core (which was actually part of what prompted us to create RTK in the first place) [1].
FWIW, we explicitly recommend RTK as the standard way to write Redux logic [2], and now that Redux Toolkit 1.3 is out with some new APIs [3], my next task is to create a new "Quick Start" tutorial page for the Redux core docs [4] that does actually teach Redux using RTK as the default syntax, ie, "this _is_ how you write Redux code", in the same way that the Apollo docs teach Apollo-Boost as the default way to use Apollo.
[0] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...
[1] https://github.com/reduxjs/redux/issues/3321
[2] https://redux.js.org/style-guide/style-guide#use-redux-toolk...
[3] https://github.com/reduxjs/redux-toolkit/releases/tag/v1.3.0