Taking this logic to the extreme, several languages let you define functions within other functions. Since everything is ultimately just used by main, why not define
everything in main?
Well, those local functions usually capture context too, so every local variable of main is now effectively global - with all the difficulties of reasoning about widely shared global state that brings. On large codebases you now have a main function that's millions of lines of code - a bit hard to reason about.
In a less extreme example, I more commonly I see functions in the several thousand lines of code range. John Carmack has actually argued for this "style C" at least in some cases: http://number-none.com/blow/john_carmack_on_inlined_code.htm... . When it's a simple linear flow like those examples, I'm even relatively OK with that style!
But IME clean examples like that are the exception, not the rule. Most functions with thousands of LOC have very high cyclomatic complexity scores too, and are hard to reason about. I have significant trouble keeping track of invariants and edge cases in such code. Ultimately, it can be done, but you have to figure out how to digest such code into bite sized chunks of functionality and what they operate on.
Functions declare in code those chunks, imposing some limits on how they interact with other chunks - only interacting through global, member, or input variables. You're forced to give them names, which are much better maintained than the section comments.
OTOH - 1 line functions used in one place? I'm quite willing to inline those. And larger functions. There's a sweet spot to cater to - something about how much code you can reasonably keep in your head and reason about all at one time.