An opinion from someone's who been doing web dev since the 90s (and who had to learn Perl and frames before jQuery + Bootstrap):
For me the big one is componentization. For example, take a look at https://mui.com/material-ui/all-components/. It's kinda like Bootstrap in that it's a bunch of UI widgets that you can easily compose into a site. But using React gives you an orderly way of maintaining and sharing state across these components, turning an API response (or several) into a tree of states that can be easily used, modified, and shared across components and pages. The jQuery way of doing that (in the old days, at least) would typically be global vars or else each widget handling its own fetches and data. But it's not easy to pass that kinda stuff between widgets. In React + TypeScript it becomes very simple, once you learn it, to make such a dashboard with loading states, notifications, graphs, popups, etc. all synced to each other.
But, that said, not every site needs that kind of complexity. (And especially not every site needs Next.js on top of React). If you're doing a simple blog, React is frankly overkill and will add unnecessary complexity. These days, you probably don't need jQuery either. Modern ECMAScript is pretty good.
The dislike of React, IMO, is partially because it's designed to solve medium-biz-to-enterprise-scale web problems where several devs have to work together on a codebase of sufficient complexity. It is hard to do that with the code soup of jQuery + Bootstrap because every component (or at least every page) tended to have its own way of doing things. React, especially with a modern framework, tends to enforce a top-down way of fetching state and storing it in some store and then propagating that down to pages and components, which means that each page becomes like a function... you can properly separate its inputs from its outputs. That means one dev can be responsible for the inputs (like an API response, or a structured state derived from the response) while another dev can focus on making/modifying the UI around that response, all without touching other parts of the codebase.
That initial problem, once solved, then created a HUGE explosion of secondary things, like serverside rendering/static building (for performance reasons), package management (NPM, yarn, etc.) for tracking & locking third-party package versions, various state management libs (for really complicated frontends... most don't need anything like that), routers (because React was born in the clientside single-page-app infancy, alongside Angular and other hash-based clientside routers)... but all of those things aren't really "React", just things that people added TO React in order to make it more batteries-included (because they wanted to keep using React, but React didn't have those things out of the box). That's a different, after-the-fact approach vs something like Angular which tried to include those bolts from the get-go (and had an even higher learning curve, and died shortly thereafter).
Next.js in particular is the combination of many of those concerns, rolling up package management, typescript, serverside rendering, etc. into one "convention, not configuration" setup that you can deploy with a single `create next app` command and deploy onto Vercel in 2 minutes. It's an incredible framework for those who need its power, but it's also a lot of complexity for those who don't.
Honestly, if jQuery is working fine for you (and your clients don't need anything more complex), all I'd consider doing is seeing if you can replace jQuery with modern ECMAScript selectors/methods. But there's no reason to jump ship to React unless you have a professional need for it.
If you do (like your frontends are getting more complex), I'd also investigate other frameworks/libs too, like Svelte, Vue, maybe HTMX, etc. and see which one fits your needs the best. The only significant advantage that React has over those is hireability/popularity. It's become the de facto business-scale frontend (way more than the others), even though it's not the easiest to learn or use.