If the object had a stack-bounded lifetime, the borrow checker would have been able to prove the analysis though. The advice is to clone things it can't, which pretty much requires that it go into the general heap. I'm sure there are some interesting counterexamples, but the situation you're imagining seems kinda academic.

The fact something goes to heap doesn’t necessarily mean it needs more heap allocations. I’ve had it many times that I instantiated a new object on heap and had to pass cloned arguments to it (because it had to own them), yet they ended up as inline fields, so no additional allocations. Happens a lot with Rc / Arc.

Once more: if the compiler can see to inline the object or put it on the stack or replace it with a by-value/in-register copy, then the borrow checker wouldn't have puked to begin with. The advice is very clearly to make heap allocations as a way to evade borrow analysis. I don't see why that's controversial.