I agree that many differences between programming languages are differences between programming styles where it cannot be said that one variant or the other is definitely better, but only that one variant is more suitable for some people while the other variant is more suitable for other people.
Nevertheless, I have been careful to not choose an example of this kind, but one where there is no doubt about what is right and what is wrong.
I am curious how do you justify that it is a good thing for a programmer to waste time to think whether a function should be invoked as f(x) or f(&x) and to waste time and page space with writing and reading "&" symbols, when this wasted time cannot bring any contribution to solving whatever problem needs to be solved.
Choosing whether to pass parameters by value or by reference is a problem of the same nature as the allocation of the hardware registers, which does not belong to a high-level language. The C keyword "register" is now obsolete, but the parameter-passing method should have become obsolete at the same time. Of course, for this to become possible, the direction of the parameters must be specified, to allow a correct compiler decision. When the direction of the parameters is specified, "const" no longer needs to be specified, because it is implied by "in".
Moreover, like I have said, any language that does not distinguish out parameters from in-out parameters, but which nonetheless allows the definition of new data types, together with mechanisms for their allocation, initialization, and deallocation, becomes excessively complicated, because it must add a special kind of functions that support one "out" parameter, i.e. the constructors, despite the fact that normal functions do not support such parameters, and then for each new type several kinds of distinct constructors and operators are needed, e.g. copy constructor, move constructor, assignment, which would not have been needed otherwise. When out and in-out are distinguished, assignment is not an operator, like in C++, but only a syntactic separator. In languages like C++, the programmer also needs to annotate some operations, so that they will use the kinds of implicit constructors that will be efficient in that context.
So if the defined data types can be used in any ways in which primitive types are used, then the mess of C++ is unavoidable. If there are restrictions on how the defined types are used, e.g. when operators cannot be overloaded or when various other such restrictions are enforced, then some of the complications of C++ can be avoided but such restrictions are even less desirable.
So between a single super simple rule of specifying in all function prototypes whether the parameters are in, out or in-out and having to keep in mind a great number of rules of how to deal with constructors in general and with several kinds of special constructors, in order to achieve acceptable performance when handling large objects, I do not see how there can be alternative views about which is right and which is wrong, except when they are based on lack of familiarity with the right solution.
When out and in-out parameters are distinguished, there are no constructors as a special category and no worries about them. An object can be initialized with any function that has an out parameter of the correct type. The only constructor is the default constructor, which is an ordinary function that needs to be specified only so that the compiler will invoke it implicitly when there is no explicit initializer.