Could you give an example of a commonly-used library that serves this purpose?
Both of those examples are _specifically_ about using React to do the actual DOM manipulation.
React-Bootstrap is a set of React components that know how to generate the correct HTML structure and classnames to get the matching Bootstrap styles. As part of that, I believe some of the jQuery-centric logic in Bootstrap has been implemented in just React.
For drag and drop especially, you're having to approach the problem from a different mental model. You can't just `$(".my-list").sortable()`. React wants you to describe your UI based on _state_ rather than doing raw DOM manipulation, so libraries like react-dnd and react-beautiful-dnd do the work to tie together drag events with the underlying logic to drive React re-rendering.
But in both these cases, you're not "using other libraries to do DOM manipulation". React's doing the work. These libraries are just helping tell React what the DOM should be.
The thing is that we could s/react/jquery/ and end up with a more-or-less believable argument for why "jquery is needed for complex apps": You can't just `draggable=true`. jQuery wants you to describe your UI in terms of a plugin's options object rather than doing raw DOM manipulation; libraries like jquery-ui do the work to tie together drag events with underlying logic (e.g. snap) to drive jQuery re-rendering. You're not "using other libraries to do DOM manipulation"; jQuery's doing the work. Etc.
Of course a library on top of react/jquery/whatever will generally be written in a way that is idiomatic for code written on top of its respective base framework. For library writers like you and me, it might even make sense to argue that React rendering model is nicer for writing libraries on top of than jQuery. But that's a developer-oriented mindset, which, as the_gastropod had alluded to, it's very often at odds w/ a user-oriented mindset.
The "old beard" approach slices through all the abstraction layers and simply points out: huh, you don't need context and css-in-js and themes to do dark mode, plain CSS fits the bill. And when one resets assumptions enough times and start noticing more often than not that "complex" projects turn out to be glorified CRUD apps, one might indeed start to wonder if the abstractions are really as fitting for the task at hand as they should be.
If state management is so critical to running a react app than I feel Elm/ClojureScript is a better choice than react to build web apps. But I doubt they will be as popular given network effect.
Now everyone went on a bandwagon that react/angular/SPA/progressive apps is the only future and plain HTML/CSS/JS mix on server side with specific language templates is dead. I am sure we will again go full circle back as you can see now with SSR (server side rendering) is considered as a norm for performant react or angular apps. SSR combined with complexity of react/redux unnecessarily makes everything complicated (worse than even complex). Instead of doing HTML templates in nicer language on server side now people are forced with half baked solution on client side like JSX or angular templates etc.
A developer not just need to learn intricacies of HTML/CSS/JS, but then API's of framework like react, combine it with state management framework, combine it with client side templates, combine it with build tools like gulp, webpack, combine it with NPM, Yarn, combine it with babel compiler, combine it with many testing frameworks. The whole eco-system is very complicated (not just complex).
This is one of the reason for emergence of compiler based web application development language and frameworks like Svelte, Elm, ClojureScript, PureScripts. They will still be not popular because there is a network effect of jobs available. So inferior tools for user interface like react/angular will continue to thrive.
Well it is not dead, but with the rise of Webapps (not Websites!) come use-cases you can only handle with SPAs. One major example is the new youtube feature, where the video playback is not interrupted when you click on a link somewhere (the video stays at the right bottom corner of the page and keeps plaing). No way to do this with SSR.
Other examples include staying in fullscreen mode (think automatic playback of video playlists) - with SSR, every video change would trigger a page reload and thus require user interaction to go back to fullscreen.
SPAs are not required for Websites, but for Webapps there are a lot of cases where SSR is not possible or would result in poor UX.
A decent dark mode is going to take a lot than a class at the root in any case (a class at the root makes a good toggle, sure, but you have to do all the styling if particular elements that that toggle applies.)
If you have handrolled CSS for your light theme and want to add a dark theme toggle, hand rolling CSS for it and toggling with a class at the root is pretty idiomatic React.
If you've chosen a styling/theming library to solve other problems, or incidentally to doing so as might have happened if you chose Material-UI, then, sure, a class at the root might not work well, and/or you might have a much easier solution (not easier than the class at root but easier than the rest of the work of implementing a dark theme) for adding a toggleable dark theme. Like in Material-UI, where you just tell the theming solution you’d like the computed dark version of a theme.
Another observation that I've been finding interesting about "modern frontend development" is that despite all the arguments about how React makes DOM manipulation easier, people still prefer to defer to libraries to do any non-trivial amount of DOM manipulation rather than actually use pure React to do it. This is exactly the same modus operandi as when jQuery was "modern frontend development" ("it makes it easier to work w/ DOM", plus a ton of opaque jquery-* libs)