Opcodes that end in VERIFY generally do not leave anything on the stack. What's so different and the reasoning when designing these opcodes that CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY opcodes leaves something on the stack and hence has to be succeeded with the DROP opcode?
1 Answer
This is because CSV and CLTV are NOP opcodes that were redefined in a softfork.
As a softfork can only change the validity of transactions from valid to invalid, the only effect this redefinition was allowed to have is making the script abort in some conditions, and keep acting like NOP otherwise.
NOP does not pop anything off the stack, and as a result, neither can CLTV and CSV. Otherwise a script like "0 n CSV 0 EQUAL" would go from invalid to valid.