Now I’m really puzzled, why it is discouraged in elixir?

I am not sure about Elixir, but personally I can find these reasons where with is preferred to catch

1. Dialyzer. Consider this code

defmodule Throwing do

  def f(x, y, z) do
    divide(divide(x, y), z)
  end

  defp divide(_, 0), do: throw :oops
  defp divide(x, y), do: x / y

end

defmodule With do

  def f(x, y, z) do
    with(
      {:ok, xy} <- divide(x, y),
      {:ok, xyz} <- divide(xy, z)
    ) do
      xyz
    else
      :this_clause_doesnt_handle_anything -> :error
    end
  end

  defp divide(_, 0), do: :error
  defp divide(x, y), do: {:ok, x / y}

end

Dialyzer will only warn us about with, but it won’t warn about unhandled throw :oops

lib/sample.ex:1:pattern_match
The pattern can never match the type.

Pattern:
:this_clause_doesnt_handle_anything

Type:
:error

And the problem here is not just a dialyzer problem. Even a programmer won’t be able to figure out whether the thown value is handled somewhere up the callstack or is it just a develop who forgot to write a proper catch.

2. Debugging
   Let’s assume, we don’t use dialyzer and we forgot to write catch clause to handle throw. The process will just fail, and all we’ll have is stacktrace of this throw. Now, with with we’d also have a place where we failed the matching, which will provide us an information on what was expected against what was received in match.

3. Performance
   throw collects stacktrace information when it traverses the stack in search of the matching catch clause. with doesn’t do that

See the benchmark:

defmodule Throwing do

  def f(x1, x2, x3, x4, x5) do
    {:ok, divide(divide(divide(divide(x1, x2), x3), x4), x5)}
  catch
    :oops -> :error
  end

  defp divide(_, 0), do: throw :oops
  defp divide(x, y), do: x / y

end

defmodule With do

  def f(x1, x2, x3, x4, x5) do
    with(
      {:ok, r} <- divide(x1, x2),
      {:ok, r} <- divide(r, x3),
      {:ok, r} <- divide(r, x4),
      {:ok, r} <- divide(r, x5)
    ) do
      {:ok, r}
    else
      :error -> :error
    end
  end

  defp divide(_, 0), do: :error
  defp divide(x, y), do: {:ok, x / y}

end

Benchee.run(%{
  "throw" => fn ->
    :error = Throwing.f(1, 2, 3, 4, 0)
  end,
  "with" => fn ->
    :error = With.f(1, 2, 3, 4, 0)
  end
}, [
  warmup: 1,
  time: 5,
  memory_time: 2
])

"""
Operating System: Linux
CPU Information: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
Number of Available Cores: 8
Available memory: 15.35 GB
Elixir 1.13.4
Erlang 24.3.4.5

Benchmark suite executing with the following configuration:
warmup: 1 s
time: 5 s
memory time: 2 s
parallel: 1
inputs: none specified
Estimated total run time: 16 s

Benchmarking throw...
Benchmarking with...

Name            ips        average  deviation         median         99th %
with        10.11 M       98.90 ns ±39076.74%          29 ns          90 ns
throw        8.27 M      120.93 ns ±24530.51%          61 ns         170 ns

Comparison:
with        10.11 M
throw        8.27 M - 1.22x slower +22.02 ns

Memory usage statistics:

Name     Memory usage
with            120 B
throw           120 B - 1.00x memory usage +0 B
"""

Most of the exception workflows in the programming languages I worked with are frowned upon because they pass the responsibility for error handling in their own code to upstream callers. Which would be fine – if it was more visible.

(Java has checked exceptions that can be appended to the function signatures e.g. public void do_stuff_with_file(String path) throws IOException which helps but I’ve noticed many former colleagues have been outright ignoring those.)

So #1 reason for me is: code must be obvious through and through, 100%, including any and all errors it can return.

Code must not have surprising effects. Code should be “what you see is what you get”.

Actually throw isn’t for exceptions, it is exactly meant as an early return mechanism.