When a function call returns a value, that means a function call is an expression which can be used within other expressions where a value is expected. Consider an expression like f() + g() for example. If f and g had out-parameters instead of return values, then this could not be written as an expression; you would need to write something like

int f_out, g_out; f(&f_out); g(&g_out); f_out + g_out 

This is impractical, and so even when languages support out-parameters, generally you can also return values, and out-parameters are only used for the cases where returning a single value from a function isn't sufficient.

So it's not really a question of choosing between out-parameters (or pointers) vs. return values; you should generally have return values, and then decide if you want to also support out-parameters. The main argument against out-parameters is that they transmit function results as a side-effects ─ calling the function mutates the variable passed in, changing the program state.

One of the most consistent things in the evolution of programming language design over the last several decades has been to prevent side-effects, particularly mutation, either by forbidding them entirely or by enabling the programmer to avoid them where they are unwanted. It's widely considered that immutability and function purity are beneficial even in the imperative paradigm, since mutation is the source of whole categories of bugs.

Clarity. Returns are easier to grok then out parameters.

I might be making some enemies here... But out parameters smell. And they smell worse then old fish. There is nothing inherently wrong with an out parameter... But there are a couple of downsides to using them.

Consider:

int x = foo(); 

what does this function do? no idea, but I know that it is returning an int which is assigned to x. That much is really clear. And with better function/result names I can learn everything I need to about the function by just looking at the function call. No need to inspect it.

what about if we have a function that uses an out parameter such as:

int x; foo(&x); 

What is happening here? no idea. What I know is that foo takes a pointer to x, I don't really know what it does with that pointer... maybe it assigns it a new value.. maybe x is supposed to have a value and foo takes an int pointer as an input so there is an error here... I cannot say without looking at foo's documentation.

Now increase the complexity, and create more complicated function calls. That require multiple inputs, have multiple outputs etc...

"But out parameters allow for multiple returned variables"... SRP (single responsibility principle), A function should do 1 thing. Multiple outputs are a sign that a function is doing too many things. If it really needs to return multiple values because they are related, why aren't you keeping those variables together as a struct to make certain that nothing is lost or mixed?

The subset of functionality offered by returns vs out parameters is a good thing, because it encourages better coding practices, makes code more readable, etc...

Various languages have, over the years, developed many different ways to handle returning values from functions -- often simultaneously. They tend to serve different needs.

A single return value is convenient because it allows easier composition of expressions that would otherwise have to be captured into variables and later operated on separately.

Output/reference parameters are convenient where a value is produced as a side effect (especially where not always needed). There's an interesting side argument here whether it's better to pass a null pointer in when a particular side output is not required -- this allows the callee to skip computation of the value, which might be a performance benefit; but also requires conditional logic, which might be a performance loss.

Reference parameters are convenient where you want your function to sometimes leave a value unchanged, or when you want the caller to control the memory allocation.

Modern language design seems more inclined to gravitate towards returning multiple values for the cases where a single function has multiple logical returns, typically combined with a destructuring assignment or similar to then decompose these into individual variables for later use.

Others argue that multiple return values are a code smell and should be rewritten to separate function calls, or introduce a new class that encapsulates the combined result (e.g. did you really want to return a bool,value pair or is that better expressed as an optional<T> or a ResultOrError<T> etc?). Typically this sort of thing only works well with generic/template types or it can lead to an explosion of tiny types, especially for one-off use cases.

Ultimately it's going to come down to a question of how strongly opinionated do you want your language to be, and whether it's a low-level language where people want to finely control memory allocation or a higher-level language where such things are more abstracted.

It is easier to read the code where arguments and results are possible to tell apart without viewing the signature of the function:

(r1, r2) = f(a1, a2) 

is more easy to understand than something like f(a1, a2, r1, r2).

As seen in the example, multiple return values are also possible with tuples that can be immediately unpacked into separate variables (r1 and r2).

If r1 and r2 are more tightly coupled (like X and Y co-ordinates of the location, for instance), it is usually advocated that the function should return the properly defined structure instead, that would name the values for clarity. Tuples are more recommended when the values are not very related, like location and error code, for instance.