Some thoughts:
I will typically not return {:ok, <data>} unless the function may also return {:error, <data>}. The extra ceremony of the result tuple doesn’t really provide any value if the only options are the value or raising/crashing/other non-result.
Just :ok. At first I did return {:ok}… not so much because I gave it any thought but it was my default because I was just starting out with Elixir, and as you point out, it felt consistent. I later reverted all that to just be :ok. As I got better versed with prior practice in Elixir, the common libraries used like Ecto, and having made use of a number of Erlang OTP modules, there seemed to be a preference to not wrap a plain :ok atom return value in an extra data structure. So while {:ok} felt more immediately consistent with {:ok, <data>} I chose to have greater consistency with common practice. I expect that anyone newly coming to my code would be on slightly firmer ground if my code met familiar existing practice.
And maybe that’s the guidance I would really offer. Any set of documented guidelines will probably be better if some deference is given to historic practices… using perhaps the Elixir/Erlang Standard Libraries & OTP as a reference point… or at least explain why those historic practices are not being adopted when they might otherwise apply. They might not be the best, or even clearly consistent (for example, I see Erlang’s ETS module returning <data>, {ok, <data>} | {error, reason}, ok, but also true) but in general they are expected.
Other notes related to your questions (from my point of view).
Function parameters I will typically make explicit/individual required parameters. Some deference in ordering is made to how a function might be part of a data transformation pipelines such that |> usage is more natural. Optional parameters are Keyword lists & maps. The exception to this in my code is when the “record” (generically speaking) is the parameter. Changeset functions with Ecto are a good example of this, both the starting data struct and the changes are single parameters (usually) because the record itself is the value, albeit a complex one.
Return data will in part depend on if I expect the function to participate in data transformation pipelines or not. If so, the return value is built to facilitate that usage across the functions that it might be expected to work with. Otherwise it really depend on the consumer of the result.
so a good official guide about this would be super useful