Oops! One number is wrong in the first column, so you update it, and everything updates automatically. No muss. No fuss.
This is the model that Svelte works in BY DEFAULT. The compiler determines a dependency tree. Variable "b" depends on "a" in a component, you've bound "b" to an element for display, and somewhere, your components logic changes the value to "a". Boom! UI is updated with latest calculation, and all you had to do was use plain ole JavaScript. No useState(). No complete DOM subtree rewrites since the virtual DOM was marked dirty, just the bare minimum of DOM changes automatically.
Reactive variables instead of linking up reactive functions within a reactive framework API.
In React, for performance reasons, you often have to explicitly mark segments of a component (or whole components) that you know won't change so that it doesn't recalculate every time there's a minor property update.
All of that goes away in Svelte. There is no reason to mark segments for no recalculation in Svelte in the first place. It just works, and it just works with what looks to you as the developer as 99% HTML, vanilla JavaScript, and standard CSS.
I imagine most folks who love React syntax have Stockholm Syndrome at this point. Having written for web since 1996 or so, I've seen the progress as well as the fads. I still remember document.write(…) and Netscape's layer tag. I remember the JQuery revolution after the missteps of Prototype. I know full well why React (and Angular and Vue) were created as web sites became larger and more complex.
And I'll tell you truthfully, I haven't been this excited about a return to relative simplicity as evidenced by Svelte in a long time. The strategy behind Svelte is an industry refactor that's been a long time coming. Even if Svelte is not the eventual "winner", I truly hope it's something closer to the Svelte model than the current old guard of Angular, React, and Vue.
You may claim to hate magic, but I have some bad news: there is magic at every level going down to the lightning injected into rock to make it think. The fear of magic is the same argument used by the assembly programmers when C first emerged. "Too much magic. Too easy. Too much loss of control." Never mind that it was an order of magnitude easier to learn, modify, and maintain.