I just happened upon the statement in the title. The full quote is:
As a rule of thumb, make all your methods virtual (including the destructor, but
Is there anything to it?
The advice is BAD, there is no question about it. Reading something like that would be enough to stay away from the book and its author.
You see, virtual keyword indicates "you can or should override this method - it was designed for this".
For any non-trivial task, I cannot imagine a reasonable system of classes that would allow user (i.e. other programmer) to override every single single method in every derived class. It is normal to have base abstract class with only virtual methods. However, once you start making derived classes, there's no reason for slapping "virtual" onto everything - some methods don't need to be extensible.
Making everything virtual means that at any point of code, no matter which method is called, you can never be sure that the class will do what you want, because somebody could have overriden your method, breaking it in the process (According to Murphy's Law it will happen). This will make your code unreliable, and hard to maintain. Another very interesting thing is the way virtual methods are called in constructors. Basically, by following this advice you sacrifice code readability/reliability in exchange for not doing a quite uncommon typo. In my opinion, it is not worth it.
In comparison, non-virtual method guarantees that no matter what happens, at this point of code, the code will always work as you expect (not counting the bugs you haven't discovered yet). I.e. somebody else won't replace your method with broken alternative.
The advice reminds me a common error some newbie programmers tend to do: instead of developing simple solution that will fix the problem, they get distracted and attempt to make code universal and extensible. As a result, project takes longer to finish or never becomes complete - because universal solution for every possible scenario takes more effort/development time than a localized solution limited only to current problem at hand.
Instead of following this "virtual" advice, I'd recommend to stick with Murphy's Law and KISS principle. They worked well for me. However, they are not guaranteed to work well for everybody else.