Why Do Inputs Have to Been in Update (Rather than FixedUpdate)?

Well input can be read in FixedUpdate, just not input events like GetKeyDown, GetKeyUp, GetButtonDown, GetMouseButtonDown, .... That's because those events are only true for one frame. By frame we talk about an actual visual frame. Input is always read / updated at the beginning of a frame. During a frame the input information doesn't change.

The FixedUpdate mechanism (physics processing) is implemented just before Update is called each frame. However it's possible that FixedUpdate is not called each frame when your visual framerate is high. Usually the fixed framerate is set to 50 fps by default. That means if you actually have 100 visual FPS FixedUpdate only runs every second Frame in order to get the 50 calls per second. If the framerate is 60 fps FixedUpdate will be called almost every frame but every 6th update it will not call FixedUpdate. If a down or up event happens during such a frame, you will not detect it in FixedUpdate.

I've made a simple simulation years ago to visualize how FixedUpdate works. This originally was a WebPlayer. Recently i've created a webGL build of it. Set the "FPS" slider to your actual framerate. The magenta boxes represent a single FixedUpdate call. Note the yellow vertical line which indicates the current Time.fixedTime while the thick red line represents Time.time Note you can slow down the simulation speed and zoom in / out to get a better view of what is happening. (Note: You shouldn't zoom out completely. WebGL could run out of memory. This wasn't an issue in the WebPlayer but WebGL is very limited)

I've created a CustomFixedUpdate class that can be used to implement as many fixedupdate callbacks at any rate you want. It works exactly like Unity's fixedupdate. Just have a look at the implementation to better understand what Unity actually does. In essence beside the normal game time Unity keeps a seperate timeer (fixedTime) which is incremented each time FixedUpdate is called. Though unlike the normal time where the increment each frame can vary, the fixedTime is always increase by the set fixedDeltaTime value. Unity calls FixedUpdate as long as the fixedTime lags behind the current game time. If the actual framerate is high it's possible that a single fixedTime step jumps over a whole deltaTime period. So the next frame the fixedTime is still ahead of the current time so no FixedUpdate will be called.

FixedUpdate is fixed to a set time scale or ticks. If a frame takes 10 seconds (hypothetically) it will call FixedUpdate hundreds of times to catch up for all the missed ticks. There is no way to pick up Input calls on those ticks reliably.

Update is called based on your frame rate along with every other system besides anything using continuous physics. FixedUpdate is almost never needed, or rather should not be used in normal cases. If you want to be micromanaging bullet physics or adding constant force to RigidBodies then yes it has it's uses, but for most players it's not something you should be using.

Input goes in Update along with 99% of everything else.

I am not 100% sure but I don't think that FixedUpdate loops like Update does.