In fact, this can reduce overhead. And in rare cases, increase it.
If you have a pointer to final class A , any calls to virtual methods can be de-dialized and called directly. Similarly, a call to the virtual final method can be de-virtualized. In addition, the final class inheritance tree is fixed even if it contains the virtual parent classes, so you can de-virtualize some parental access.
Each of these de-virtualizations reduces or eliminates the requirement to query the runtime structure (vtable).
There may be a slight flaw. Some encoding methods rely on vtable access to avoid direct access to the character and then not export the character. Access to the vtable can be done using a symbol (without symbols from the library, only the header file for the classes in question), while access to the method is directly related to binding to this symbol.
This breaks down one form of dynamic linking of libraries in C ++ (where you do not link more than the dll load symbol and / or C-link functions that return pointers, and classes are exported via their vtables).
It is also possible that if you are linking to a symbol in a dynamic library, loading a symbol in a dynamic library can be more expensive than searching in a vtable. I did not experience or profile this, but I saw how he claimed. Benefits should generally outweigh such costs. Any such value is a problem with the quality of implementation, since the cost is not required, because the method is final .
Finally, final prohibits the empty base optimization trick in classes where someone knows that your class has no state and inherits it to reduce the overhead of "storing" an instance of your class from 1 byte to 0 bytes. If your class is empty and does not contain virtual methods / inheritance, do not use final to avoid blocking. There is no equivalent for final functions.
Besides the EBO optimization problem (which happens only with empty types), any overhead from final comes from how other code interacts with it, and will be rare. Much more often, this speeds up other code, since direct interaction with the method allows a more direct method call, and can lead to optimization detonation (because the call can be better understood by the compiler).
Marking anything other than an empty type as final when it is final is almost certainly harmless at runtime. Doing this on classes with virtual functions and inheritance is likely to be useful at runtime.
std::is_final and similar features are almost all implemented using the built-in compiler magic. A good amount of traits in std requires such magic. See How to determine if a class is final in C ++ 11? (thanks to @Csq for determining this)