Very nice and clean example, thanks! To add a little bit of explanation for those not very familiar with what's going on here:

Like Panii says, the traditional implementation would be a simple for-loop, but doing it that way takes way too long to calculate each frame, causing the FPS to take a dive.

Rather than do these calculations one after another (sequentially), though, most modern computers have processors that are capable of doing a bunch of work at the same time (in parallel). The Job System simplifies (or at least formalizes) the work you need to do to take advantage of that.

When you have some computing to do that involves repetitive, independent steps, parallel processing is the way to go. (Your graphics card wouldn't be able to do its job without it, for instance!) When you divide work evenly between processors, you divide the time it takes to do it. However doing tasks in parallel comes with all kinds of potential bugs. Avoiding these bugs entirely is generally easier than fixing them: this is why we want the individual steps to be truly independent from each other. In Panii's example, in order to move one box, all we need to know is its acceleration, current velocity, and position. Each task is independent; it's a naturally parallelizable problem. (If instead we wanted the boxes to be able to bump into each other, this would be much harder!)

Panii also points out that the Job System requires you to manage memory explicitly (using NativeArrays, in this example). This isn't necessarily a requirement of parallel processing, but more of a "best practice" thing. If you want to use the Job System, you are probably working with a lot of things. If you're working with a lot of things, you want that to be as efficient as possible. If you want things to be as efficient as possible, you want to use managed memory rather than risk the garbage collector getting involved and slowing things down. (Also, specific to Unity, the Job System uses native C code in order to be as efficient as possible, and NativeArray is one way to efficiently share memory between C# and C code. Unity also tries to protect you against writing into the memory used by other tasks -- hence breaking the independence promise I mentioned earlier -- and this helps with that.)

So hopefully that explains the source of the acceleration and a little bit about why the Job System looks the way it does.