The short answer is YES, it is a bad practice to use dynamic.

Why?

dynamic keyword refers to type late binding, which means the system will check type only during execution instead of
during compilation. It will then mean that user, instead of programmer, is left to discover the potential error. The error could be
a MissingMethodException, but it could be also a not intended call to an existing method with a bad behavior.
Imagine a call to a method that ends in computing a bad price or in computing a bad level of oxygen.

Generally speaking, type checking helps to get deterministic computing, and so, when you can, you should use it. Here’s a question on shortcomings of dynamic.

However, dynamic can be useful…

• Interop with COM like with Office
• Interop with languages where dynamic types are part of the language (IronPython, IronRuby) as dynamic was introduced to help porting them to .Net.
• Can replace reflection complex code with low ceremony, elegant code (however depending on the case, you still should profile both approaches to check which one is the most appropriate in terms of performance and compile-time checks).

Code base is evolving throughout the application life cycle and even if dynamic seems ok now,
it set a precedent which can implies an increase of dynamic keyword usage by your team. It can lead to increased
maintenance costs (in case the above stated signature evolves, you can notice it too late). Of course, you could
rely on unit tests, non regression human tests and so on. But when you have to choose between human discipline related
quality and automatically checked by computer related quality, choose the later. It’s less error prone.

In your case…

In your case, it seems you can use the common inheritance scheme (the first one below and the one you mention in your question),
as dynamic won’t give you any additional benefit (it will just cost you more processing power and make you incurring
the risk of future potential bugs).

It depends on whether you can change code of MyClass hierarchy and/or Caller.InvokeMethod.

Let’s enumerate
the different possible alternatives to dynamic…

• Compiled type-checked alternative to dynamic keyword method call:

The most common is using interface virtual call like this instance.InvokeMethod() with inheritance calling the right implementation.

public interface IInvoker : { void InvokeMethod(); }
public abstract class MyBaseClass : IInvoker { public abstract void InvokeMethod(); }
public class MyAnotherClass : MyBaseClass { public override void InvokeMethod() { /* Do something */ } }
public class MyClass : MyBaseClass { public override void InvokeMethod() { /* Do something */ } }

Another a little less performant is by using Extension Methods

public static class InvokerEx:
{
    public static void Invoke(this MyAnotherClass c) { /* Do something */ } }
    public static void Invoke(this MyClass c) { /* Do something */ } }
}

If there are several “visitors” of MyBaseClass hierarchy, you can use the Visitor pattern:

public interface IVisitor 
{
    void Visit(this MyAnotherClass c);
    void Visit(this MyClass c);
}

public abstract class MyBaseClass : IInvoker { public abstract void Accept(IVisitor visitor); }
public class MyAnotherClass : MyBaseClass { public override void Accept(IVisitor visitor) { visitor.Visit(this); } }
public class MyClass : MyBaseClass { public override void Accept(IVisitor visitor) { visitor.Visit(this); } }

Other variants though not very useful here (Generic method) but interesting for the performance comparison:

public void InvokeMethod<T>(T instance) where T : IInvoker { return instance.InvokeMethod(); }

• Dynamic alternative to dynamic keyword method call :

If you need to call a method not known at compile time, I’ve added below the different techniques you could use and updated the performance results:

MethodInfo.CreateDelegate

        _method = typeof (T).GetMethod("InvokeMethod");
        _func = (Func<T, int>)_method.CreateDelegate(typeof(Func<T, int>));

Note: Cast to Func is needed to avoid call DynamicInvoke (as it is generally slower).

DynamicMethod and ILGenerator.Emit

It actually build the full call from scratch, it’s the most flexible but you must have some assembler background to fully appreciate it.

        _dynamicMethod = new DynamicMethod("InvokeMethod", typeof (int), new []{typeof(T)}, GetType().Module);
        ILGenerator il = _dynamicMethod.GetILGenerator();
        il.Emit(OpCodes.Ldarg_0);
        il.Emit(OpCodes.Call, _method);
        il.Emit(OpCodes.Ret);
        _func = (Func<T, int>) _dynamicMethod.CreateDelegate(typeof (Func<T, int>));

Linq Expression

It’s similar to DynamicMethod, however you don’t control the IL generated. Though, it’s really more readable.

        _method = typeof (T).GetMethod("InvokeMethod");
        var instanceParameter = Expression.Parameter(typeof (T), "instance");
        var call = Expression.Call(instanceParameter, _method);
        _delegate = Expression.Lambda<Func<T, int>>(call, instanceParameter).Compile();
        _func = (Func<T, int>) _delegate;

MethodInfo.Invoke

The last but not the least, the standard known reflection call.
However, even if it’s easy to mess with it, don’t use it as it’s really a bad performer (look at the benchmark results). Prefer CreateDelegate which is really faster.

        _method = typeof (T).GetMethod("InvokeMethod");
        return (int)_method.Invoke(instance, _emptyParameters);

Code of the benchmark test can be found on GitHub.

Benchmark of the different methods to get an order of magnitude (for 10 Millions of call) (.NET Framework 4.5):

For Class standard call:
Elapsed: 00:00:00.0532945
Call/ms: 188679
For MethodInfo.CreateDelegate call:
Elapsed: 00:00:00.1131495
Call/ms: 88495
For Keyword dynamic call:
Elapsed: 00:00:00.3805229
Call/ms: 26315
For DynamicMethod.Emit call:
Elapsed: 00:00:00.1152792
Call/ms: 86956
For Linq Expression call:
Elapsed: 00:00:00.3158967
Call/ms: 31746
For Extension Method call:
Elapsed: 00:00:00.0637817
Call/ms: 158730
For Generic Method call:
Elapsed: 00:00:00.0772658
Call/ms: 129870
For Interface virtual call:
Elapsed: 00:00:00.0778103
Call/ms: 129870
For MethodInfo Invoke call:
Elapsed: 00:00:05.3104416
Call/ms: 1883
For Visitor Accept/Visit call:
Elapsed: 00:00:00.1384779
Call/ms: 72463
 == SUMMARY ==
Class standard call: 1
Extension Method call : 1,19
Generic Method call : 1,45
Interface virtual call : 1,45
MethodInfo.CreateDelegate call : 2,13
DynamicMethod.Emit call : 2,17
Visitor Accept/Visit call : 2,60
Linq Expression call : 5,94
Keyword dynamic call : 7,17
MethodInfo Invoke call : 100,19

EDIT:

So comparing to Visitor pattern, dynamic dispatch is just about 3 times slower. It can be acceptable for some applications as it can remove cumbersome code. It’s always up to you to choose.
Just keep in mind all the drawbacks.

---

EDIT: (as an answer to multiple dispatch benefit)

Using trendy pattern name like ‘multiple dispatch‘ and just state that it’s cleaner because it uses less code, doesn’t make it an added benefit IMHO.
If you want to write trendy code or don’t care about type safety and production stability, there are already a lot of language out there offering full feature dynamic typing. I see dynamic keyword introduction in C# as a way to close the gap between the strong typed language family and not so strongly typed other languages. It doesn’t mean you should change the way you develop and put type checks to trash.

UPDATE: 2016/11/08 (.NET Framework 4.6.1)

Orders of magnitude remain the same (even if some of them have improved a bit):

Class standard call: 1
Extension Method call : 1,19
Interface virtual call : 1,46
Generic Method call : 1,54
DynamicMethod.Emit call : 2,07
MethodInfo.CreateDelegate call : 2,13
Visitor Accept/Visit call : 2,64
Linq Expression call : 5,55
Keyword dynamic call : 6,70
MethodInfo Invoke call : 102,96