Really getblocks should have been called getblockhashes , as the response contains just block hashes, not full blocks.

Every block can be observed in three different ways:

• The full block, containing all transactions and header information.
• The block without the transactions, but just the 80-byte header which includes a Merkle root committing to the transactions.
• Just the 32-byte hash of the block header (which is used to identify the whole block, and is thus also called the block hash).

getblocks was designed to be used for synchronizing blocks. The usual sequence was that node A would send a getblocks, B would respond with an inv with block hashes, A would reply with a getdata for each block he's missing, and B would send over the full blocks using block messages. The limit was 500, as downloading more than 500 blocks at once was presumably deemed too much and pointless (as that could be up to 500 MB of data).

getheaders on the other hand was designed for headers synchronization, something at the time only used by lightweight clients. These would not download (all) full blocks, and the headers sent in response would generally be the only futher communication. As headers are only 80 bytes per block, even 2000 of them is just 160 kB of data.

Since the introduction of headers-first synchronization (which essentially uses getheaders to learn about block hashes and headers simultaneously, and then download missing blocks from multiple peers at once), the old getblocks based synchronization is superseded (it's still implemented for compatibility with software that doesn't have headers-based sync, but other than that inferior in every way except implementation complexity).