I haven't read the studies referenced here, but I'd be concerned about mistaking correlation for causation here. Long methods may or may not be bad, but the temptation to write them usually arises when the programming task is already complex. The error rate may reflect the complexity of the task, rather than the approach (long methods vs short ones).
That's a good thought, but it only explains why routines longer than 200 lines would be more error-prone. It doesn't explain why shorter routines were also showed a higher defect rate.
If I am making a change to long method I can understand what this method is doing. I am more likely to take care in making changes because I can see the potential problems and I have a visual indication of the complexity of the code. Also I might be less likely to make changes unless necessary because of the complexity.
When working on a shorter method, changes are easier to make and the context and complexity are hidden. The side effects of the changes are harder to see, so I am more likely to make a change which can break things and not know that it will cause problems.
Unit testing should provide a measure of protection against this kind of problem (side effects of changes). The actual experience of writing, updating, and running the tests adds its own complexity, though, so I'd view them as a big help, but not an easy to apply solution.
