Here is a shorter (untested) solution:

trigger callResult on Task (after insert) {
    Map<Id, Lead> m = new Map<Id, Lead>();
    for (Task t : Trigger.new) {
         if (t.WhoId != null && t.WhoId.getSObjectType() == Lead.SObjectType) {
             m.put(t.WhoId, new Lead(Id = t.WhoId, Status = t.CallDisposition));
         }
    }
    update m.values();
}

with some opinions:

• The signature of the trigger - the after insert - determines when the trigger is called so no need to double check in the body of the trigger.
• It's unlikely (but possible when a bulk update is done) that multiple Tasks related to the same Lead are handled in the trigger so for safety the map ensures only one reference to the Lead in the update.
• Id values know the type of object they reference so you can stick to a strongly type SObjectType comparison rather than using describe calls and string prefix comparisons.
• Only handle exceptions when you have a clear reason to do so: most exception handling code is counter productive.
• It's been may API versions since updating an empty list counted against governor limits; empty list guards are not needed.
• Move logic out of a trigger into a separate class when you have reason to do so. The benefits must outweigh the reduced cohesion.

Here is a shorter (untested) solution:

trigger OnTaskInsertUpdateLeadStatus on Task (after insert) {
    Map<Id, Lead> m = new Map<Id, Lead>();
    for (Task t : Trigger.new) {
         if (t.WhoId != null && t.WhoId.getSObjectType() == Lead.SObjectType) {
             m.put(t.WhoId, new Lead(Id = t.WhoId, Status = t.CallDisposition));
         }
    }
    update m.values();
}

with some opinions:

• The signature of the trigger - the after insert - determines when the trigger is called so no need to double check in the body of the trigger.
• It's unlikely (but possible when a bulk update is done) that multiple Tasks related to the same Lead are handled in the trigger so for safety the map ensures only one reference to the Lead in the update.
• Id values know the type of object they reference so you can stick to a strongly type SObjectType comparison rather than using describe calls and string prefix comparisons.
• Only handle exceptions when you have a clear reason to do so: most exception handling code is counter productive.
• It's been may API versions since updating an empty list counted against governor limits; empty list guards are not needed.
• Move logic out of a trigger into a separate class when you have reason to do so. The benefits must outweigh the reduced cohesion.