Is the use of dynamic considered a bad practice?

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

I don´t fully agree with Fabien that it does not give you additional benefits. What he is solving with the visitor pattern is called Multiple dispatch and dynamic can provide a clean solution to this too. Sure you have to know the implications Fabien mentioned like performance, static type checking...

public abstract class MyBaseClass
{
}

public class MyClass : MyBaseClass
{
}
public class MyAnotherClass : MyBaseClass
{
}

public class ClassThatIsUsingBaseClass
{
    public static void PrintName(MyBaseClass baseClass)
    {
        Console.WriteLine("MyBaseClass");
    }

    public static void PrintName(MyClass baseClass)
    {
        Console.WriteLine("MyClass");
    }

    public static void PrintName(MyAnotherClass baseClass)
    {
        Console.WriteLine("MyAnotherClass");
    }

    public static void PrintNameMultiDispatch(MyBaseClass baseClass)
    {
        ClassThatIsUsingBaseClass.PrintName((dynamic)baseClass);
    }
}

And usage is

static void Main(string[] args)
{
    MyBaseClass myClass = new MyClass();
    MyBaseClass myAnotherClass = new MyAnotherClass();
    ClassThatIsUsingBaseClass.PrintName(myClass);
    ClassThatIsUsingBaseClass.PrintName(myAnotherClass);
    ClassThatIsUsingBaseClass.PrintNameMultiDispatch(myClass);
    ClassThatIsUsingBaseClass.PrintNameMultiDispatch(myAnotherClass);

    Console.ReadLine();
}

Output is

MyBaseClass
MyBaseClass
MyClass
MyAnotherClass

Search for "Multiple dispatch" and "C# multiple dispatch" for more infos.

This was answered in 2015, today in 2019 with the patterns we see in JavaScript and Typescript indeed there are good reasons for using dynamic; however, it requires the developer to take caution.

    private (Boolean Valid, dynamic Result) ValidatePersonID(int ID)
    {
        var person = _store.Persons.FirstOrDefault(person => person.ID == ID);
        if (person == null)
        {
            string message = $"The person id {ID} does not exist, please try again.";
            return (false, message);
        }
        return (true, person);

    }

To use the code above:

   var operation = ValidatePersonID(personID);
   if (operation.Valid == false)
     {
        //BadRequest takes a string and C# uses co-variance to make it work.
        return BadRequest(operation.Result);
     }
   //otherwise just cast the type, but requires the cast to always work.
   var pe = (Person)operation.Result;
   ...

The return of validity being either True, or False determines the type being returned. We still pick up strong typing using the cast and or the required input type on BadRequest. We also pick up compile time type checking in that if one of the two returned types ever changes to something other than string, and or person, it won't compile.

I consider this a form of Dependency Injection whereby we achieve different behaviors depending on what we inject. C# purists don't like this idea but Typescript people do it all the time.