Well, I can see at least one drawback: if the class is derived from specific interface, then the dynamic_cast solution will always return interface, which means that the class implements the functionality. But sometimes the class is derived from parent, that implements the interface, but the child (not yet) implements the interface, then the soluton using dynamic_cast is unable to support this. The existing approach using giveInterface method can deal with that, as the child can always overload the giveInterface.
We can discuss whether it is a good desing, when parent implements the interface and child not, but it can happen (and is the case already in oofem).

I agree with some of your points, however, I still think that the ability to implement just a raw class (like an element having just plane structural capability) that is derived from existing element without the need to implement (or check) all interfaces enforced by parent, can be beneficial. We have many small student projects, where students just adapt the existing elements or material models, but they simply don't need any error estimation capability, etc, imposed by one of interfaces. They just want to get basic structural capability, however, the base class already enforces some interfaces. Then it is in my opinion better and safer to mark those as not supported, as opposed to pretending automatic interface implementation. And in principle, this allows to accept such an basic element/material into oofem (as the basic functionality is required in most cases and could represent a significant contribution). If not able to selectively implement interfaces, we could not in principle accept such an incomplete class, and that could be a pitty for us.