Many times you will have dependencies in sub-classes, or may have to implement things differently.

class BasicCarModel
{
    public virtual void Accelerate(double speed)
    {
         RotateFrontWheels(speed);
    }
}

class LuxuryCarModel : BasicCarModel
{
    public override void Accelerate(double speed)
    {
        RotateAllWheels(speed);
    }
}

There is nothing at all wrong with creating virtual methods in concrete classes and in some cases they are very useful. The difficulty is that many novice programmers violate the Liskov Substitution Principle when doing so. Remember that an overridden method should appear to do the same thing if used as a base method. It should not strengthen or weaken the preconditions of the base method.

In the example I gave, the difference between the base class and the derived class was in the mechanics of how the car accelerated, not in the values allowed for speed. It did not throw any exceptions that were not expected by a calling class.

This is a contrived example, but the principle is the same. Do use virtual and override when needed. Don’t violate the LSP.

Here’s a non-abstract class which does some processing, and a sub class which only does processing at certain times of day.

class Foo
{
    public virtual bool IsReadyToProcess()
    {
        return true;
    }
    public void Process()
    {
        if (!IsReadyToProcess()) throw new Exception("Not ready");
        else
          // Process
    }
}

class TimeboundFoo : Foo
{
    public TimeboundFoo(int hour) { Hour = hour; }

    public int Hour { get; private set; }

    public override bool IsReadyToProcess()
    {
       return DateTime.Now.Hour == Hour;
    }
}

Usage:

List<Foo> foos = new List<Foo>();
foos.Add(new Foo());
foos.Add(new TimeboundFoo(12));

foreach (var foo in foos)
{
   if (foo.IsReadyToProcess()) foo.Process();
}

At noon, it’ll process both Foo objects, but at any other hour it’ll only process the one.
It’s a very contrived example, but you can generalize from here.

Virtual/abstract methods and overriding are commonly used in. Template pattern.

The template pattern provides a way to define what you think would be a good general guideline for a class to follow, but you allow future implementers to be more specific, or even unique in their way of doing something.

How about a simple case where you MUST use override:

Any class that implements the IDisposable interface. (And any class that owns a resource that must be cleaned up should implement it.)

Note: The OP mention that it seems OK to you to override base implementations of abstract classes, so this answer is tailored around that assumption.

It’s probably a bad idea to inherit from classes which were not designed for inheritance (see why are concrete types rarely useful as bases for further derivation). Many of the C# experts believe that C# classes should be sealed by default.

See also Why Are So Many Of The Framework Classes Sealed?.

All that being said, the only difference between an abstract class and a concrete class that was designed for inheritance is that the latter can be instantiated. Alternatively, a concrete class is like an abstract class that has no methods lacking some form of default implementation. All of the design considerations that make it OK to inherit from an abstract class also make it OK to inherit from a concrete class that was designed for inheritance.

An interesting example is UserControl. Being able to derive from UserControl is of high value, since there is a lot of asp.net functionality which leverages polymorphism.