does react really need nodeJS on the frontend ENV?
The answer to the question posed in the title is no, you do not need node.js to use React on the client side.
In fact, the second example you give is doing just that - using React on the client side without any mention of node.js.
That said, there are a couple of different ways to use node.js that are very useful when building React-based applications.
Use a node.js-based build tool like browserify or webpack to bundle your client-side code into a neat, tidy package which you then serve to the client.
For example, in a project I'm working on, I use browserify to build a single Javascript file saved at public/js/bundle.js which is included via a plain old <script> tag in my index.html and it's all served by Apache. This bundle contains my application code (including some React components) along with all the dependencies for my application code (including react and react-dom, among other things). The main benefit for the client is to reduce the number of requests for the page and the bandwidth required (since I can use UglifyJS to minify the whole bundle). The main benefit for the developer is that you can use tools such as Babel to write .jsx code instead of plain old Javascript - this is a tremendous boost to productivity.
Write an HTTP Server in node.js
There has been a lot of buzz in recent years about building the entire app with node.js - client-side and server-side. The main benefit here is code reuse: imagine that you wrote a library that does something fancy with dates. If you're writing your client-side code in Javascript and your server-side code in PHP, then you'll have to rewrite that library; if you're using node.js on both sides, you only need to do it once.
Write an HTTP Server in node.js and integrate it with your React application
Single-page applications (SPAs) written with React have a problem: the page doesn't get rendered until the Javascript code is received and executed by the client. This means that clients that don't execute Javascript won't see anything - such as Google's web crawler. So if you want your page indexed, you'll need to figure out some way to serve a fully-rendered page when a client makes a request. The solution to this is server-side React rendering. This is quite a challenging topic, and I'd encourage you to do some Googling if your interested in it.
Now as for your question: which is better? As always, it depends on your needs.
One of my projects is a legacy PHP application where I'm rewriting some of the front-end code to use React components. Do I need a node.js HTTP server or server-side rendering? No, not at all. But I am using Babel and Browserify to make my life as a developer easier.
Another of my personal projects is a small SPA written using a framework called Next.js which is pretty cutting-edge, incorporating server-side rendering. I could certainly have written this project using other technologies, but I do like the shared codebase between client and server that this affords.
I think the current accepted answer is missing some key information. The answer is true - Node.js is not needed - but one of the first reasons you will encounter it is often used is that people prefer to use JSX format when writing React.
JSX will not work in browser just like that. You can use for example babel-standalone to help browsers cope with JSX, but that means that your JSX code will be compiled again on every pageload, which isn't efficient. What's more efficient is to compile JSX while building the site, server side. Most of such tools are node based, so that's one of the reasons Node.js is often used.
There are, of course, other reasons, JSX thing is just one of the first. There are plenty of additional javascript ecosystem related tooling that also come with Node.js. Those can be used also on, for example, java system, but it is always a bit hacky. In practice you will encounter that for different libraries and additional resources, the instructions to use tend to be given mainly for Node ecosystem, leaving others more up to the user.