I don't use React for speed. I use it because manipulating the DOM to make it reflect the application state is hard. It's something a program should do for me. React is that program.
I don't get a lot of opportunities to play around with JS frameworks, which is odd because I hobby-code a lot in JS. I imagine the top reasons to use frameworks are cross-browser compatibility and support for scalability in the domain of your work. Unfortunately sometimes people use them because the only tool they have is a hammer, so everything is a nail. Vanilla DOM manipulation has become much easier in the past few years. I have played around with some new DOM features in my own time, but for anything public-facing I'm going to use a library that allows for cross-browser compatibility, and typically that's a combination of jQuery, polyfills, etc.
It's not that it is hard to `document.createElement` compared to `React.createElement`, it's just that React has a nice paradigm of syncing your app state to what's displayed to the user which many people like. Sure it might be better somewhere else, but React is what is popular and more easily accessible.
I don't think it's hard. If you really think it's hard, I think you can study React's architecture and discern that you can accomplish what you want with React--or with smaller, different libraries in accordance to your use case.
I, too, did a double-take at the use of the word, but I looked it up, and it seems to be a valid usage. Various dictionaries define program merely as a "set of instructions," so, yeah, a library or framework counts as a program just as much as a separate process.
I used "program" because that's what we call things that automate things for us, and that's the appropriate frame for thinking about React: it automates things you could've done by hand, but why do that?
