Author's disclaimer: This is a HUGE topic and I'm going to give a fairly brief treatment. Consider this a starting place for the question, not the answer.
In Scala, methods are all virtual by default. You can opt-out with the "final" keyword, and even partially opt-out for inlining by sealing the class. In C#, methods are non-virtual by default. You opt-in with the "virtual" keyword. It is worth mentioning that overridden abstract methods are virtual, implemented interface methods are non-virtual in C#, but that's not the point.
There is a deep philosophical difference here. Scala expects class consumers to override methods. You can even override with an anonymous class in a method. Very powerful, kind of bugs me out. In C#, the expectation is that the base class author should have more control over how consumers will use their stuff, and there are potential efficiency gains that go along with that.
There may be no greater metaphor for the relationship between the open-source-centric Java world and the closed-source Microsoft world than this single design decision. As a guy who prefers writing core library/infrastructure code, I think I prefer the Microsoft approach here, but the power of mix-ins and anonymous overrides in Scala are pretty darned cool.
Let's consider these classes, defined in vaguely agnostic and very explicit pseudo-code:
class Foo { methodA; methodB; virtual methodC; }
class Bar inherits Foo { new methodB; override methodC; }
When the instance of type "Bar" has been cast into a reference of "Foo," which bodies to call?
The answer depends on how the method was declared:
barInstance.methodA => Foo.methodA
((Foo)barInstance).methodA => Foo.methodA
barInstance.methodB => Bar.methodB
((Foo)barInstance).methodB => Foo.methodB
barInstance.methodC => Bar.methodC
((Foo)barInstance).methodC => Bar.methodC
#1 and #2 are equivalent, for obvious reasons. Bar didn't declare a body for methodA, so you have to invoke Foo.methodA. But how do #3/4 and #5/6 differ? Syntax aside, the answer is that virtual methods are referenced from a v-table. The instance is carrying around it's type information, which has a table of pointers to implementations. When you call methodC, the instance looks the body up in the table and invokes it. However, methodB is not virtual; it is invoked on the type. So if an instance of Bar is masquerading as a Foo, it had better be ready to invoke Foo's body for methodB.
This is a powerful thing! The naive way to think about these things strongly favors the behavior of virtual methods, but there is a cost. Virtual methods pay for that v-table lookup. Much more importantly, it is very easy to inline non-virtual methods at compile time. Inlining virtual methods cannot be done until JIT time, and even then is path fraught with danger. In other words, non-virtual methods can significantly more efficient to call. How significant depends on how much work the method is doing in its body, YMMV.
