I'm rather curious about this source article. There may be something context specific in it. Do you have a link?
A function call is an unconditional branch, which makes it non-equivalent to an if/else or a loop, which uses conditional branches. You can not replace a conditional branch with an unconditional one and maintain equivalent code behaviour. If you move an inner loop to another function, you'll still need the conditional branch structure for the looping inside the function, plus you'll be adding the overhead of the unconditional branch to enter and leave the function.
Function calls can add significant overhead in some cases. In the case of adding two numbers together, a function call would add significant overhead. Inlined code could be as simple as a single add instruction, which on old CPUs take 1 clock cycle, and on newer CPUs can complete in parallel with other instructions, giving an average cost of less than 1 clock cycle. A function call to add two numbers would likely contain two push instructions to load the parameters on the stack, the call, two memory loads to load the parameters, the add, and the return. Such a simple function would likely omit function prologue and epilogue code, so there are some cost savings there, but you're still looking at 7 instructions. Using the fastcall convention, you can pass the parameters in registers, which if already conveniently loaded in the correct registers, means you can omit the two push instructions, and the two memory loads inside the function, in which case there are still 3 instructions needed. Using a function call may also have other secondary effects on optimization. The fastcall convention uses a specific set of registers to pass the values, which can increase the pressure on the register allocator, whereas an inline add could work just fine with any registers. The call and return may have implications for branch prediction, which can further increase call costs. Further, passing parameters on the stack means memory is touched, which is slower than using values in registers, although for such a simple case, the cache memory should catch this so it shouldn't incur the full cost of actually writing and reading back the values from main system RAM.
Of course if optimizations are turned on (which they won't be for a debug compile), the compiler could just inline a function call, producing equivalent output whether you wrote the code inline or as a function call. The way C++ works though, with separate compilation units and a linker, the structure of your source code could prevent this. If you wrote both functions in the same source file, or placed one function as inline code in a header file (making them both visible in the same compilation unit), and do a release build, there's a good chance the compiler will inline a small function. If you place the two functions in separate source files they probably won't benefit from inlining.
As to whether or not you should break up code into functions, that's an entirely different question. My general rule of thumb is if your function is longer than a screen full of code, you should break it up. Code readability and maintainability is usually far more important than the performance impacts of a few clock cycles. You get billions of clock cycles per second, they're not so special. You won't ever notice the overhead of a single function call. It's difficult to even measure using the high performance counters that count clock cycles. There's too much noise in the results from other effects, like caching, pipelining, branch prediction, and the general superscalar nature of modern CPUs that issue multiple instructions per clock cycle. You really need to aggregate a large number of function calls before the performance impacts become measurable, and more still before they become noticeable. For the vast majority of code, it simply doesn't matter, it will never be called often enough to matter. The usual advice is always write for readability and maintainability first. Don't worry about optimization until you have data to say it matters.
