You are right, the documentation for CALL states that a row is being returned. However if you read https://www.postgresql.org/docs/current/xproc.html#XPROC 'Procedures do not return a function value; hence CREATE PROCEDURE lacks a RETURNS clause. However, procedures can instead return data to their callers via output parameters' this does not sound like a row being returned.
Correct, because from the perspective of the procedure all it is aware of is it's output arguments. The caller is either SQL CALL or plpgsql (or someone else) which deal with those outputs differently.
Also plpgsql does not do it when you invoke CALL. The libpq documentation does not mention CALL of a stored procedure with out params at all. Maybe it should, - somewhere.
It's better from a pure separation of concerns if libpq has no awareness that CALL was the command only seeing that whatever the SQL a tuple exists on the wire to be processed.
That is the crux of the hesitation here, you are breaking encapsulation/isolation of concerns. Libpq has little need or desire to be aware of the specific SQL commands being passed around. It is a client-server message passing protocol.
