Explicit virtual is form of Defensive programming. By enforcing what methods can be overriden, you ensure that person who will create a child class cannot create error by doing something that wasn’t intended by parent’s design.

I don’t think it has anything to do with how people approach design of their code from composition vs inheritance point. But there are definitely people who will dismiss it on basis that defensive programming is not good thing.

I think it could, yes. Virtual by default would make it a lot easier to override implementations in inherited classes.
Frankly, I think it’s a weird rule. If you really need to override something, then make it virtual. Don’t go making everything virtual just because some guideline tells you to.
It sounds like stuff you’d hear in college (overarching advice that could bite you in the backside when applied without second thought).

I am puzzled as to why a book on testability would be recommending creating virtual methods, unless it is speaking more to a C++ audience than a C# audience.

Making methods virtual should be done only with great care and caution. Most classes I write that are not explicitly abstract are generally sealed. That way I can be sure that the code that I write is rhobust and thoroughly tested. I can be sure that no other developer is going to inherit my class, violate the Liskov Substitution principle and throw some kind of exception in the code that I have written.

If a developer follows the SOLID principles, particularly the last one (dependency inversion), testability should not be a huge concern. It’s when these principles are violated that testing becomes a lot harder.

Here are my rules of thumb for writing testable code:

1. Avoid writing static methods/classes.
2. Follow the SOLID principles.
3. Seal as many classes as is practical and use the virtual keyword very sparingly.

With dependency injection and mocking tools tests are easy to write (even if some become long because of the data that is required to test against).