While reading about Internet Protocol, I found myself reading about ping of death attacks: the thing that attracted my curiosity was the fact that these attacks could ever work!
I mean, why wasn't IPv4 packet dropping (for packets larger than 56 byte + header) immediately implemented on computer systems? Was/is there a reason for a host to receive a packet larger than 84 byte total?
There are many reasons why packet dropping isn't implemented. One example is that there is a technology known as jumbo frames, which allows for up to 9000 bytes of payload. These are primarily supported on LANs where large amounts of data are moved around, and where the repetitive nature of headers is unnecessary.
It's also worth noting that most packets are larger than 56 bytes + header. The standard Ethernet frame size is 1500 bytes. If you are referring solely to ICMP packets, it would be possible to implement such a restriction, but why? There are valid use cases for wanting larger ICMP packets. Having a network stack that properly handles non-standard packets is generally more desirable than having a network stack that arbitrarily limits functionality.
Was/is there a reason for a host to receive a packet larger than 84 byte total?
There are several layers involved here, and that's the first part of the problem. ICMP's 84 bytes for a ping message header (the payload can be larger... you can put whatever you'd like in the payload field) mean that the packets have to be received by the system on the wire protocol, reassembled into the larger packet on the IP protocol if there's fragmentation, passed on to the ICMP layer which will then check the protocol type and only after all of that can you length check it.
There are many places when writing code to allocate memory that you can make mistakes along the way. For example since you can't get more than 64k of data in a valid IPv4 packet, you might allocate a 64k memory buffer. Then when you assemble the fragments, you may be in trouble if you didn't check that the sum of the fragments is less than the allocated memory size. A specific failure made was trusting the length header of the last possible fragment as always valid within the whole reassembled packet even though the maximum offset packet wasn't allowed to be full size without breaking things.
Thus you can't immediately drop most packets without reassembly. You could add a match check on the last packet size (if offset > x and offset * 8 + len(y) > 64k), but that would require checking extra bits in the packet which is really only suited at the firewall and host levels.
The internet only works because everyone has agreed to follow the standards of TCP/IP. Ping packets larger than 56 bytes+header are allowed by TCP/IP, and simply dropping them because your implementation can't handle them would be breaking TCP/IP.
The problem with the Ping Of Death wasn't the design of TCP/IP, but an implementation problem. You don't change the rules of valid IP packets because one vendor didn't write their code properly.
As to valid uses of large ping packets, it can be useful in chasing down other network problems. A simple example is determining the MTU between you and another host by setting the packet size lower and lower until it isn't fragmented.
There are a couple of good answers here already.
I wanted to add that packet filters, firewalls, and IPSs can handle this kind of thing. These kinds of devices are frequently configured to disregard the normal rules of TCP/IP to be able to drop correct, but malicious, traffic. Examples include large ICMP packets, fragmented TCP packets, crafted packet headers, and many others that are correctly formed, but problematic for all too frequently buggy TCP/IP or app protocol stacks.
Rules like this cannot be baked into all devices as it would make TCP/IP non-functional in general for reasons the other answers have described: 1) need for specialized packet sizes in diagnostics 2) need for large/jumbo packets for efficiency (ex: SAN throughput with lower overhead)
