"prefer composition over inheritance" is because in most cases composition is the better solution. However, in some cases, inheritance is better, and IMHO the patterns you have done so far are not only examples of when inheritance is better, but actually re-implement limited forms of inheritance.
Your delegate decorator "automatically filling in 'non-overridden' methods" re-implements inheritance without virtual methods. This has the limitations you identify in this article, that you fix by crudely making a virtual method in the base class that you call a "strategy". If you made all the methods in the base class different callable "strategy"s, then congratulations, you will have re-implemented a virtual method table. Inheritance is
just composition made less verbose. Note your strategy solution undermines the biggest benefit of the delegate pattern; you can wrap an existing object instance when you don't have control over how it was created (ie, an object returned by some other library that you can't easily modify).
I agree that using inheritance where composition would be better is a common mistake. However using composition where inheritance would be better is also a mistake.
Most people learn inheritance badly. It doesn't help that most popular languages implement it badly (broken multiple inheritance, not enforcing polymorphism, etc). IMHO if you didn't learn inheritance from Eiffel (or maybe Oberon for exposure to under-the-hood implementation details), you mostly learned it wrong, and probably missed some really important concepts.
The combination of bad language support, bad education, and abstraction pain debugging the resulting bad inheritance hierarchies seems to have started a major backlash against inheritance. IMHO it's now going too far, and inheritance is being avoided even when it really is the best solution.