In the excerpt, the child transaction does not signal opt-in RBF (nSequence of 0xff_ff_ff_ff) while the parent transaction signals opt-in RBF (nSequence of 0xff_ff_ff_fd). By the virtue of the parent transaction being replaceable, the child transaction should also be replaceable.
This means that without your child transaction also signalling opt-in RBF, reference client do not consider inheritance signalling and thus you cannot execute an RBF with that child transaction. You can see how it affects the various clients in that email as well. It isn't really a "critical" vulnerability in Bitcoin Core, it is just a policy that was defined in BIP125 but never actually enforced. It can be problematic for the applications outlined in that email.
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.
Just to add. For normal transactions, most users in general either wait for a single confirmation before accepting a transaction. Even if they don't, then there isn't a problem because the vulnerability doesn't allow non-replaceable transactions to be replaced. PR has been merged in the main branch, so should be included in the next release.