For me, one of the biggest reasons for breaking a method up into distinct tasks or concerns is rooted in the expressiveness of exception messages. Below is an exception message on an actual production website. I am not going to show the code, but I had to answer the question, “Where did the exception below get called in the Page_Load method?” This particular method is a monster that is over 300 lines of code with multiple points where multiple reference objects could be the reason for the null. If the method was broken down into distinct concerns, I would have a fighting chance of finding the source of the error in less than an hour. Hell, with distinct methods I can probably find the null as soon as I expand the method.

Target: Void Page_Load(System.Object, System.EventArgs)
 Type: System.NullReferenceException
 Exception Message:
 Object reference not set to an instance of an object.
Exception StackTrace: at Page_Load(Object sender, EventArgs e)
 at System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e)
 at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e)
 at System.Web.UI.Control.OnLoad(EventArgs e)
 at System.Web.UI.Control.LoadRecursive()
 at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Do your code a favor, do the people that will be maintaining your code a favor, break up your god classes and methods into bite sized chunks of related functionality.