Because Erlang's "if" doesn't work like that. It looks like this:

    if
        IfBoolean -> "case statements only";
        true -> "you didn't get a choice"   % yes, it's "true", not "else"
    end

In fact, Erlang's "if" is actually an if-elif chain that takes guards (unlike "case" which takes patterns) as test conditions: those are restricted set of expressions that basically allow only constants, variables, arithmetic/boolean operators and comparisons and very few built-in functions (mostly of the is_type/1 sort), and that's it. Guards are evaluated one by one until one of them evaluates to true; if none do, a run-time error is raised.

It's a very unwieldy construct and at my org, we mostly try to avoid it because "case" is clearer in like 98% of the cases.

I think the argument is that it's exactly the same, so why learn both? I've definitely lost seconds (maybe even minutes) to refactoring if statements into case statements and vice versa in Haskell.

Why have two things that do exactly the same?

Because it's more readable and easier to write

That's your opinion, but I also get messages from people saying the opposite.

My hunch is that familiarity is actually what makes something more or less readable.