What was the intended benefit of truncating the Target? I'm thinking about how the Target value is truncated to and later compared to the SHA-256hash of the Block Header.

Given that 

The maximum target (lowest possible difficulty) is
0x00000000FFFF0000000000000000000000000000000000000000000000000000
and the current target is
0x00000000000004985C0000000000000000000000000000000000000000000000
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (4bits * 32 = 128)  
                                  This part is always zero due to truncation                              


Question:


Is it simply there to make coding and evaluation easier?
Does this make the mining operation faster (more efficient comparisons)? 
Are the efficiencies of the previous bullet endian-specific?
Are there statistical benefits or drawbacks to making it non-zero? (fractionally easier to find a block?)


I haven't seen a thoughtful explanation of why the decision was made, and I don't want to infer anything on my own.
I suspect that the target is truncated so it will not consume too much space in the blockchain.  

The blockchain stores a compact form of the target in a "bits" field that is 4 bytes wide.  This is (significantly) less than 32 bytes (256 bits) representing a SHA256 hash.

For context:


The space savings is exactly 28 bytes per block.
As of 2/28/13, a block count of 223693, that's 6,263,404 bytes or roughly 6MB that was saved with this optimization.  This data optimization applies to data-on-disk, and what is sent to miners from pool operators