Some limited degree of mutual authentication occurs inherently as part of the Kerberos authentication process between client and app service. A service should not be able to decrypt the service ticket unless it has the key associated with the Kerberos principal it is supposed to be. If it can't decrypt the service ticket then it shouldn't have access to the information about the user principal it needs to properly authenticate and create a session for that user.
Now, I imagine a malicious host that is able to impersonate a legitimate service could pretend it was able to decrypt the service ticket and create a generic session for any user contacting it. In some cases -- such as accessing an internal web site to which all employees have permissions -- it may not be obvious to the user that they are not authenticated in their proper context. In other cases -- such as accessing a personal file share -- it should be quickly obvious that the service doesn't have the data the user expected and is fake.
The Kerberos mutual authentication process proves to the client that it is talking to the proper service principle, rather than assuming if a session was established that it is with a valid service.
The reason mutual authentication isn't turned on by default is probably due in part to the difficulty of an attacker successfully tricking a client into thinking a malicious service is a valid service (e.g. via DNS spoofing), and then actually benefiting from this deception. In addition, it is a small performance benefit to eliminate the mutual authentication step from the authentication process.