Given the task you describe, compiling a Bable project, and the CPUs involved I think I know the source of the difference in performance. I wanted to answer earlier but had to do a bit of research to confirm my hunch.
First, let's characterize the load you're putting on your system.
Babel.js is written as a single-threaded, single process compiler that mostly leverages asynchronous I/O for parallelism (at least nothing I've googled indicates it using worker threads). Since it is a compiler that compiles files from disk a large part of its execution involves waiting for data from disk. This gives us the following workload:
Single-threaded so multiple cores or hyperthreading have no significant effect on compilation with one caveat:
Node.js uses worker threads to handle disk I/O but beyond a two or four hardware threads there is no additional advantages to multiple cores (see: https://nodejs.org/en/docs/guides/dont-block-the-event-loop/)
Most of the parallelism takes place at the I/O level. Babel will try to read as many files in parallel as possible.
Both the i5 and the Xeon are fairly comparable with regards to points 1 and 2. So let's look at how the CPU can handle point 3: servicing Babel's parallel file read request.
Here's the first big difference between the two systems:
So clearly the Xeon can handle more parallel I/O operations than the i5. When there's more I/O than the number of memory transfer lanes available the OS handles it the same way as when there's more tasks than number of hardware threads available: it queues them up and force them to take turns.
Next I wanted to know if NVME can actually use multiple lanes. This is where I hit another interesting fact. The NVME standard allows a card to use up to 4 PCI lanes (there is physically that many connections allocated) but some cards use only 2 while others use 4. So not all NVME cards are created equal. This alone will give you double the number of files Babel can copy to RAM in parallel at almost double the bandwidth.
It also depends how the NVME slot is connected to the CPU. The Core i5 having only 16 PCI lanes will no doubt be reserving at least 8 of them for the GPU. Leaving you only 8 to be shared among other devices. This means that sometimes your NVME card will have to share bandwidth with your Wifi or other hardware. This slows it down a bit more.
And your NVME may not even be connected directly to your CPU's PCI lanes. The Macbook may actually reserve all 16 lanes for the GPU and connect to your NVME via its south bridge (which may have additional PCI lanes). I don't know if the Macbook does this but this again may reduce performance a bit more.
In contrast, the large number of lanes that the Xeon has allow the motherboard designer much more freedom to create a really fast I/O platform. In addition the AWS server does not normally have a GPU installed so it does not need to reserve any lanes for GPU use. Again, I don't personally know the actual architecture of AWS servers but it's possible to create one that outperform a Macbook at compiling Babel projects.
So in the end the main factors that enables the EC2 instance to outperform the Macbook are:
Number of PCI lanes directly supported by the CPU
Number of PCI lanes supported by the NVME drive
How the NVME lanes are connected to the CPU
Additional factors that may contribute include:
The speed of the I/O bus (PCI2 vs PCI3 etc)
The speed of RAM
Number of DMA channels available (this alone requires a long answer so I sort of skipped it but the reasoning is similar to PCI lanes)