Due to efficiency and time complexity. It is basically the same reason we should keep routing tables short (but on a different level), because for every packet received, the system needs to run through the entire routing table looking for a match to know how to route that packet. This results in average and worst-case lookup times of O(n) for the length of the routing table.
Interface addresses have the same problem with similar implications. The interface may potentially have to check thousands of packets per second passing through the cable, to determine which ones are destined to this host. The simple way is: for each packet that arrives, compare its destination address to each address range assigned to that interface. Note that this is another sequential task takes O(n) for each packet, meaning: it costs processing time, potentially a lot if you have to process thousands of packets per second.
And there is another problem: as you add more and more addresses to the local link, each new address increases the memory required by all other hosts in the link, in their neighbor (ARP) tables. This is not a big problem (ARP Proxy does the same), but there is still some impact on the performance of the whole local network that you should be aware.
This makes assigning a large number of addresses to a single host a not-so-good idea. A very conservative limit like 16 or 32 is good enough, and also reminds administrators of these costs.
If you need a large number of addresses being routed to a single machine, you should make a subnet. Pick consecutive addresses all inside one subnet and route that entire subnet to that machine. Then you use some form of internal routing or some iptables/route tricks to do all the work inside the machine. This is basically what we do when hosting lots of virtual machines in a single physical server.