Explicit signaling: A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1).
Inherited signaling: Transactions that don't explicitly signal replaceability are replaceable under this policy for as long as any one of their ancestors signals replaceability and remains unconfirmed.
However, it looks to me like only "explicit" signaling is tested. See this part of the BIP125 pull request that was merged into Bitcoin Core:
It's very clear that incoming TXs are checked for conflicts (double spends) and if the conflicting TX does not explicitly signal RBF with its input sequence, then the new TX is rejected.
If implicit signaling were implemented, I would expect to see a recursive check for the conflicting TX's mempool ancestors, or check some kind of flag stored with the TX metadata.
OR, is the text of the BIP just describing what happens to descendants of replaced transactions, in that they are evicted when their explicitly-signaling ancestor is replaced.