May be many people here will not like this answer, but it is time for some heresy to be told and yes ... be told also that "the king is naked!"
All the motivation against the derivation are weak. Derivation is not different than composition. It's just a way to "put things together".
Composition puts things together giving them names, inheritance does it without giving explicit names.
If you need a vector that has the same interface and implementation of std::vect plus something more, you can:
use composition and rewrite all the embedded object function prototypes implementing function that delegates them (and if they are 10000... yes: be prepared to rewrite all those 10000) or...
inherit it and add just what you need (and ... just rewrite constructors, until C++ lawyers will decide to let them be inheritable as well: I still remember 10 year ago zealot discussion about "why ctors cannot call each other" and why it is a "bad bad bad thing" ... until C++11 permitted it and suddenly all those zealots shut up!) and let the new destructor non virtual as it was the original one.
Just like for every class that has some virtual method and some not, you know you cannot pretend to invoke the non virtual method of derived by addressing the base, the same applies for delete. There is no reason just for delete to pretend any particular special care.
A programmer that knows that what is not virtual isn't callable addressing the base also knows not to use delete on your base after allocating your derived.
All the "avoid this" "don't do that" always sound as "moralization" of something that is natively agnostic. All the features of a language exist to solve some problem. The fact a given way to solve the problem is good or bad depends on the context, not on the feature itself.
If what you're doing needs to serve many container, inheritance is probably not the way (you have to redo for all). If it is for a specific case ... inheritance is a way to compose. Forget OOP purisms: C++ is not a "pure OOP" and container are not OOP at all.