Because you need a virtual destructor and the std containers don't have it. The std containers are not designed to act as base class.
For more information read the article "Why shouldn't we inherit a class from STL classes?"
Guideline
A base class must have:
The standard containers do not have virtual destructors, thus you cannot handle them polymorphically. If you will not, and everyone who uses your code doesn't, it's not "wrong", per se. However, you are better off using composition anyway, for clarity.
Also, in most cases, you should prefer membership over inheritance if possible.
The issue isn't a philisophical one, it's an implementation issue. The standard containers' destructors aren't virtual, which means there's no way to use runtime polymorphisim on them to get the proper desctructor.
I've found in practice it really isn't that much of a pain to create my own custom list classes with just the methods my code needs defined (and a private member of the "parent" class). In fact, it often leads to better-designed classes.
One strong counter-argument, in my opinion, is that you are imposing an interface and the implementation onto your types. What happens when you find out that vector memory allocation strategy does not fit your needs? Will you derive from std:deque? What about those 128K lines of code that already use your class? Will everybody need to recompile everything? Will it even compile?
Aside from the fact that a base class needs a virtual destructor or a protected non-virtual destructor you are making the following assertion in your design:
Rates, and Charges for that matter, ARE THE SAME AS a vector of doubles in your example above. By your own assertion "...as time goes by, Rates and Charges develop personalities..." then is the assertion that Rates ARE STILL THE SAME AS a vector of doubles at this point? A vector of doubles is not a singleton for example therefore if I use your Rates to declare my vector of doubles for Widgets I may incur some headache from your code. What else about Rates and Charges are subject to change? Are any of the base class changes safely insulated from clients of your design should they change in a fundamental way?
The point is a class is an element, of many in C++, to express design intentions. Saying what you mean and meaning what you say is the reason against using inheritance in this manner.
...Or just posted more succinctly before my response: Substitution.