Let's have a look at the second claim.
To address this claim, I'm going to assume that concurrency in this context equates to scalability, since scalability is one of the primary motivations behind Node.JS. The distinction is subtle, but significant: there are many ways to get an application to scale better; concurrency is one way, but there are others. I'm also going to assume that NodeJS implements the reactor pattern, though I'm not going to describe it in great detail here.
By scalability, I mean "the ability to handle as many simultaneous requests as possible." The way that node.js does this is by providing an event loop. The event loop accepts a request from the client, and then immediately hands it off to "some other mechanism" for processing. It then returns control to the caller. This asynchronous approach allows node.js to accept many requests in a given time frame, and differs from other, more synchronous strategies, where the caller must wait for the result before continuing. The amount of processing that the event loop demands is quite small, so it is ready (or almost ready) most of the time to accept new requests.
What happens to the requests once they are handed off? Well, for purposes of our discussion, that's an implementation detail. A given request could be put into its own thread, or it could be queued on a thread containing others tasks. It could be handed to a Windows Service, or even sent to some other system for fulfillment.
The important thing to consider is the scalability that the event loop provides by making the acceptance of a request take as little time as possible. This doesn't require a separate thread for each request; all you really need are two threads (one to run the event loop, and the other to process the requests).
Naturally, if you want your request to be fulfilled in some reasonable time frame, you must throw some horsepower at the implementation detail I mentioned earlier. There is no free lunch. But that's a different practical concern than the scalability that arises by making sure that requests to a service are accepted rapidly, even though getting the results of those requests is deferred to some later time.
So when someone says something like "the reactor pattern handles concurrency better than multiple threads," they're being a bit imprecise. In a general way, they're comparing asynchronous techniques to multi-threading (asynchronous programming does not necessarily require new threads). The way I would say it is:
By using an event loop, you can abstract the acceptance of a request away from the fulfillment of a request, thereby improving scalability without incurring the unnecessary overhead of additional threads.
A Quick Introduction to How Node.js Works
Understanding the node.js event loop
An Object Behavioral Pattern for
Demultiplexing and Dispatching Handles for Synchronous Events