I can think of at least two arguments in favor of long functions:
It means you have a lot of the context around each line. A way of formalizing this: draw the control flow graph of your code. At a vertex (~= line) between function entry and function exit, you know all of the incoming edges. The longer the function, there more such vertices there are.
Many small functions means there's a larger and more complex call graph. Pick a random line in a random function, and answer the question "in which context(s) is this line executed?" This becomes harder the bigger and more complex the call graph is, because you have to look at more vertices in that graph.
There are also arguments against long functions—unit-testability springs to mind. Use t̶h̶e̶ ̶f̶o̶r̶c̶e̶ your experience when choosing between one and the other.
Note: I'm not saying your boss is right, only that his perspective may not be completely devoid of value.
I think my view is that the good optimization parameter is not function length. I think a desiderata more useful to think in terms of is the following: all else being equal, it is preferable to be able to read out of the code a high-level description of both the business logic and the implementation. (The low-level implementation details can always be read if you can find the relevant bit of code.)
Commenting on David Arno's answer:
Writing small functions is a pain because it forces you to move into each small functions to see what the code is doing.
If the function is well-named, this isn't the case. isApplicationInProduction is self-evident and it should not be necessary to examine the code to see what it does. In fact the opposite is true: examining the code reveals less as to the intention than the function name does (which is why your boss has to resort to comments).
The name makes evident what the return value means, but it says nothing about the effects of executing the code (= what the code does). Names (only) convey information about intent, code conveys information about behavior (from which parts of the intent can sometimes be inferred).
Sometimes you want one, sometimes the other, so this observation doesn't create a one-sided universally valid decision rule.
Put everything in a main big loop even if the main loop is more than 300 lines, it is faster to read
It may be faster to scan through, but to truly "read" the code, you need to be able to effectively execute it in your head. That's easy with small functions and is really, really hard with methods that are 100's of lines long.
I agree that you have to execute it in your head. If you have 500 lines of functionality in one big function vs. in many small functions, it's not clear to me why this gets easier.
Suppose the extreme case of 500 lines of straight-line highly side-effecting code, and you want to know if effect A happens before or after effect B. In the big function case, use Page Up/Down to locate two lines and then compare line numbers. In the many-small-functions case, you have to remember where in the call tree the effects happen, and if you forgot you have to spend a non-trivial amount of time rediscovering the structure of this tree.
When traversing the call tree of supporting functions, you're also faced with the challenge of determining when you've gone from business logic to implementation details. I claim without evidence* that the simpler the call graph, the easier it is to make this distinction.
(*) At least I'm honest about it ;-)
Once again, I think both approaches have strengths and weaknesses.
Write only small functions if you have to duplicate code
I disagree. As your code example shows, small, well-named functions improve readability of code and should be used whenever [e.g.] you aren't interested in the "how", only the "what" of a piece of functionality.
Whether you are interested in the "how" or "what" is a function of the purpose for which you are reading the code (e.g. getting a general idea vs. tracking down a bug). The purpose for which you are reading the code is not available while writing the program, and you will most likely read the code for different purposes; different decisions will optimize for different purposes.
That said, this is the part of the boss's view I probably disagree with the most.
Don't write a function with the name of the comment, put your complex line of code (3-4 lines) with a comment above. Like this you can modify the failing code directly
I really can't understand the reasoning behind this one, assuming it really is serious. [...] Comments have a fundamental flaw: they aren't compiled/interpreted and so can't be unit tested. The code gets modified and the comment gets left alone and you end up not knowing which is right.
Compilers only compare names for equality, they never give you a MisleadingNameError. Also, because several call sites may invoke a given function by name, it is sometimes more arduous and error-prone to change a name. Comments don't have this problem. However, this is somewhat speculative; to really settle this, one would probably need data about whether programmers are more likely to update misleading comments vs. misleading names, and I don't have that.