Citing BIP65, which introduced OP_CHECKLOCKTIMEVERIFY:

When executed, if any of the following conditions are true, the script interpreter will terminate with an error:

• the stack is empty; or
• the top item on the stack is less than 0; or
• the lock-time type (height vs. timestamp) of the top stack item and the nLockTime field are not the same; or
• the top stack item is greater than the transaction's nLockTime field; or the nSequence field of the txin is 0xffffffff;

(emphasis mine)

So OP_CHECKLOCKTIMEVERIFY requires the nSequence value of the spending input itself to not be 0xffffffff. While it technically suffices that at least one input has a non-0xffffffff nSequence, the choice was made in BIP65 to require that the input itself has such an nSequence. According to the implementation's source code, this was done to minimize the amount of data needed to prove an input is correct.

Citing BIP65, which introduced OP_CHECKLOCKTIMEVERIFY:

When executed, if any of the following conditions are true, the script interpreter will terminate with an error:

• the stack is empty; or
• the top item on the stack is less than 0; or
• the lock-time type (height vs. timestamp) of the top stack item and the nLockTime field are not the same; or
• the top stack item is greater than the transaction's nLockTime field; or the nSequence field of the txin is 0xffffffff;

(emphasis mine)

So OP_CHECKLOCKTIMEVERIFY requires the nSequence value of the spending input itself to not be 0xffffffff. While it technically suffices that at least one input has a non-0xffffffff nSequence for the spending transaction to have a relevant nLockTime, the choice was made in BIP65 to require that the input itself has such an nSequence. According to the implementation's source code, this was done to minimize the amount of data needed to prove an input is correct.