One of the premises/promises of OO is the ability to substitute implementations (in particular, dynamically, but in a modular programming sense also statically). An over-reliance on concrete classes makes this harder to achieve, and (in the context of the list, which is about testing) means you have a larger portion of the program that has to be brought into the test harness to test something.

On the former, using concrete classes instead of interfaces can be worked around if they're still configurable, but now you have inappropriate (or potentially inappropriate) subclasses to compensate for the lack of an interface. On the latter, well, it makes testing harder which is the entire point of the list. If A has two components B and C which are both tied to concrete classes and not interfaces, then you have to bring A, B, and C into the test harness when you really just want A and (possibly) B or C or stubs/mocks for them.

If you don't care about testing (and, in particular, unit testing), and don't care about substitutability, then don't worry about it.