Clarifying descendants/ancestors in error cases for too-long-mempool-chain
The ancestors of a mempool transaction T are unconfirmed transactions that this transaction T depends on in order to be included in the block chain (i.e. that are referenced by its inputs).
The descendants of a mempool transaction T are (necessarily unconfirmed) transactions that depend on this transaction T in order to be included in the block chain (i.e. that spend one or more of its outputs).
In both cases there can be multiple &quot;generations&quot; of descendants/ancestors (e.g. descendants of descendants):
         Tb
        /
Ta  ---
        \        Td
          Tc ---/
                 \--- Te
                  \___ Tf


(Here, Ta and Tc are ancestors of Te but Tb and Tf are not ancestors of Te. Td is a descendant of Tc but Tb is not.)
As you may picture from the above outstanding piece of art, their management can quickly start to be tedious hence resource intensive.
This resource usage (mostly RAM for storage and CPU to handle chain reorganization) impacts every single node not running with -blocksonly on the network, it is thus a DOS vector that must be limited. But how?
I can point you to the bitcoin-core dev wiki which reports the word of Suhas Daftuar -one of the main architects of the system that is currently in place- regarding the trade-offs of different approaches to usage limitation, but as a TL;DR:
The mempool needs to be in phase with miner incentives (don't drop the highest-paying transactions), while limiting its footprint on network nodes. Therefore, two limits are in place for the two &quot;views&quot; relative to a transaction:

The size limit, accounted for in virtual bytes, of both its descendants and ancestors.
The count limit, accounted for in number of transactions, of both its descendants and ancestors.