Why can't we put GameObject's into a NativeArray and pass them to a Job?

The Unity team explains this restriction in the documentation on The Safety System in the C# Job System as a way to avoid race conditions in multithreaded code:

The C# Job System solves this by sending each job a copy of the data it needs to operate on, rather than a reference to the data in the main thread. This copy isolates the data, which eliminates the race condition.

The way the C# Job System copies data means that a job can only access blittable data types. These types do not need conversion when passed between managed and native code.

The C# Job System can copy blittable types with memcpy and transfer the data between the managed and native parts of Unity. It uses memcpy to put data into native memory when scheduling jobs and gives the managed side access to that copy when executing jobs. For more information, see Scheduling jobs.

GameObjects are more complicated constructs, with different representations between the native & managed side (where the GameObject we use in C# is more like a handle, leading to its interesting behaviour around null / destruction)

We can't trivially copy a block of GameObjects out of the main game thread and then copy them back. For one thing, what if the object was destroyed or modified on the main thread in the meantime? References to the original GameObjects and their components wouldn't match up to the copies, so the whole thing gets pretty unwieldy to marshal back and forth to native code.

Instead, think about the logical transformations you need to perform on a group of GameObjects, and prepare a blittable data structure that contains the information needed for that transformation. Then you can use a job to perform the transformation, and upon completion, apply the results/conclusions back to your GameObjects.