If you name the functions reasonably, and the functions don't interact except through arguments and return values, you have absolutely gained something.
I did read the article. I think I'm less in favor of that style than he is (or at least was), but even he said that the problems it addresses arise from subroutines not being pure functions and so isn't a proponent of it in the case the comment you replied to was describing. And when not writing in that style, inlining is for the compiler to do.
The original poster said if you chop a big hairy complicated thing into functions to fit on a screen you've gained nothing. The response is that if they're named reasonably and pure then you have.
Now the reason I posted that inlining article from Carmack leans heavily into this line of advice: "if a function is only called from a single place, consider inlining it."
Taking a complicated mess and breaking it into functions that are called from a single place seems better served by organising the code (maybe with duplication if needed) and writing inline comments rather than devoting a call tree to that section of code.
