Considering the following, I guess the reasons are mostly based on performance and scalability.
The number of shards was redefined based on this proposal, which drastically simplifies communication between shards as they stated here. Also, the block size was increased from from
128kB in order to achieve the scalability of the previous proposal.
To support this new proposal, the total shard count to start must be
reduced from 1024 to the new estimate of 64, with the intention to
scale up the number of shards over time (~10 years) as standard
resources available to consumer laptops increases. The following are
the primary reasons for the requisite reduction in total shards:
- Each shard induces an attestation load on the network and beacon chain at each slot rather than at each epoch
- Each committee must be of a minimum safe number of validators. If there are too many committees per epoch due to high shard count, then
there couldn’t possibly be enough 32-ETH validators to safely allocate
enough to each committee
From your comment, I've done some research since I'm curious too about why 64 shards and not other number.
First, from the Ethereum 2.0 reddit AMA (Part 2) Justin Drake said (before changing from 1024 to 64 shard chains):
Q: Why 1024 shards?
JD: Because 2048 shards would be stressing the beacon chain and 512
shards would be under-utilising the beacon chain.
From Vitalik’s Annotated Ethereum 2.0 Spec
We plan to have 64 shards at the start. Having fewer shards would lead
to insufficient scalability; having more would lead to two undesirable
- Overhead of processing beacon chain blocks being too high
- The minimum amount of ETH needed to reach a full-sized committee for every shard in every slot (now 32 ETH * 128 committee size * 64 shards
per slot * 32 slots per epoch = 8,388,608 ETH) to be too high; we’re
reasonably confident we can get 8.3m ETH staking, but getting 16.7m
ETH staking would be harder, and if we can’t get that much, the system
would be forced compromise by making cross-shard transactions take