It could potentially cause problems if we ignore validity (being in range) of the parent derived keys because even though BIP-32 may look like any other Key Derivation Function but it is more than a simple KDF. For instance each non-hardened child key is derived using the parent's public key which means that parent key must have been in range to be used in EC multiplication.
BIP-44 is not relevant here but since you mentioned it, lets take the path used in this BIP:
m / 44' / 0' / 0' / 0 / 0
The bold one is the child keys used in creating addresses.
You won't notice the problem in first 3 depths since they are all hardened but the last one is not. If the parent key at m/44'/0'/0'/0 returned a key that is outside of curve range you can't derive the child key at m / 44'/0'/0'/0/0 anymore.
So the standard has to enforce this validity check on each step.
BIP-44 is not relevant here but since you mentioned it, lets take the path used in this BIP:
m / 44' / 0' / 0' / 0 / 0
The bold one is the child keys used in creating addresses.
You won't notice the problem in first 3 depths since they are all hardened but the last one is not. If the parent key at m/44'/0'/0'/0 returned a key that is outside of curve range you can't derive the child key at m / 44'/0'/0'/0/0 anymore.
So the standard has to enforce this validity check on each step.
oh, that's great to know, exactly what I wanted to learn
Follow up ques: If parent key at m/44'/0'/0'/0 is found to be valid, shouldn't I be checking the corresponding parent key of internal chain at m/44'/0'/0'/1 before assuming its safe to use? Otherwise we would have no valid change addresses to send money to.