This literally doesn't solve any actual problems. If all memory allocation patterns were lexical this is the most easy and most obvious thing to do. That is why stack allocation is the default and works exactly like this.
Now we usually cannot do "bar(foo())" because it then leaks. We could allocate a buffer on the stack, and then do "bar(foo(&buffer))", but this relies on us safely knowing that the buffer does not overflow.
If the language has RAII, we can use that to return an object which will release itself after going out of scope e.g. std::unique_ptr, but this relies on said RAII and preferably move semantics.
If the context is RAII-less semantics, this is not trivial to solve. Languages that run into this is C3, Zig, C and Odin.
With the temp allocator solution, we can write `bar(foo())` if `foo` always allocates a temp variable, or `bar(foo(tmem))` if it takes an allocator.
You seem the same in "C alternatives" such as Zig.
But obviously if you're coming from a language which already has some form of automatic memory management it won't seem like a big thing.
But in the context of manual memory management it is solving a very real problem.