I'm a self-taught programmer too (and a web dev of like 15-20 years)... can give you one opinion (and that's all this is).
IMO it's important to discuss two related but separate things:
1) Why an interactive frontend at all? IMO this is the more important question, and basically boils down to "AJAX enables better UX since you're not refreshing the entire HTML on every page load". It's better (in theory) for end-users because actions and screen loads should be a lot quicker.
But that's only relevant when comparing to serverside frameworks (like old PHP, cgi-bin stuff, old government websites, etc.). Most modern frameworks have moved to this model, and even the old PHP stuff uses it piecemeal.
That answers the "why a frontend framework at all" question, but not "why React" specifically, when Alpine/Vue/Svelte/Anything Else can do a similar job.
2) My answer to that is simply "momentum", and that's because of history. React did what AngularJS (v1) tried to but could not: gained critical mass. For a while there, it was the only major option for teams that wanted to build an enterprise-grade frontend that could be easily shimmed into their existing backend, without the overhead and overcomplexity of Angular. React then was more of a UI library than an actual framework like Angular, and so you could jam in React anywhere you needed it, but leave it out where you didn't need it.
(These days that's of course changed with frameworks on top of React like Next.js, which adds a lot of features and preconfiguration for a one-click deploy.)
But I don't think those features are why people choose React for new projects. It's again the sheer momentum of React. It's here to stay, it's well-supported, it has a huge ecosystem, and – importantly – it's easy to hire and train for. It's the most popular standard for the time being.
You can hire any off-the-shelf React dev and they can start working in your recent-ish React codebase (especially if it has no older-style class components anymore) without much additional training, because they can take your existing state object and easily build a new component on top of it and make a workable screen. But it's not just that... it's that they can move to another team, and they're probably using React too. And when they switch companies, it's probably still React. It's a skillset that has a moderate learning curve (it's really not so bad if you spend a few days on it) but then can keep getting reused at many many places and career opportunities.
By contrast the other frameworks might have many of the same important features, but they're nowhere as easy to hire for, and there's no guarantee of their future popularity/sustainability. The JS frontend world moves really really fast, and there was a period a few years ago where entire frameworks and languages (CoffeeScript, Backbone, Knockout, Ember, and of course Angular) came and went, much hyped initially but then quickly fell out of fashion in 1-2 years.
By contrast, React and Next is very firmly entrenched now and probably will stay that way for a while; they've become the Wordpress/Drupal of the frontend world, the "good enough" default option that many teams will default to.
Of course individual teams can evaluate different frameworks and choose the one most suited to their needed complexity level, but if you don't want to think about it and/or want to maximize the chances that your codebase will still be maintainable by a new team a few years from now... it's probably gonna be React. Not because it's the best, but just because it has too much momentum to die in the short term.
At a certain scale (small-to-medium-sized businesses), it makes sense to just use a "good enough" option that's widely used across the industry, because it's easy to find help for. When you're tiny (like a restaurant website or a blog or just a simple ecommerce company) it doesn't matter much because your codebase probably isn't complicated enough anyway to justify React, and whatever you do is probably going to be pretty janky anyway. When you're huge, you can design and maintain your own framework (after all, that's what Meta did with React). But in the middle, where most companies are, there's not really a good business reason to choose one of the dozen+ smaller frameworks when React will almost certainly do the job and there are so many devs for it. It's like "no one ever got fired for choosing React".
It could've been anything, really. There is no perfect framework, just frameworks that gained enough critical mass or didn't. Google really wanted it to be to be Angular, Microsoft wanted it to be .NET, but now everyone (at least in the US) just uses React. I think .NET is more popular in Europe. Once one of these frameworks gains enough popularity, it's really hard to altogether displace it. React got in at the right time, got enough critical mass, and the rest is history... regardless of its technical merit.