I've got a bone to pick with Jason Weimann 

This seems like a fun debate :) For some reason everyone keeps ignoring the big capital "TYPICAL" word in there. There always situations where methods need to be long. But it's also worth noting that you made plenty valid points that I probably didn't touch on. Definitely don't take your 2 lines of code and extract that to method for no reason. If you can't tell what the methods do without having to F12 into them, it's already a problem. But if they're named well and do what they say, it can make the code much easier to understand and onboard people into. Also very easy to go overboard and f it all up though, I've seen that plenty and even did it myself when I first started trying to clean up my code :)

The question doesn't offer the right answer as an available choice IMO. "It doesn't matter at all" is closest, but the correct answer is, "it depends." Every paradigm or standard can benefit from some abstraction or be harmed by too much. My rule of thumb is... if your method doesn't fit on screen without scrolling, it's probably time to refactor. The number of lines doesn't matter, except in that too many = bad. But we can't say, "doesn't matter at all" because "too many" is necessarily undefined until you have the context of the workstation's screen size/resolution, the IDE's font styling, the developer's visual acuity, etc.

I use plugins for cyclomatic complexity, I base my line count on analysis :) Besides it doesn't matter to me. Sometimes to many methods, the more difficult it is to read jumping from method to method.

How about none of the options. There is such thing as to big functions, but the number of lines really isn't set in stone. So it does matter, just 20 is a bit low if you ask me. That being said: These takes on inlining code are psychotic :P My simple approach here is: A method should at least be called twice to be wiorth existing (unless it's a main entry point or something like an Update)