Just my guess - not an official explanation.

I think the warning makes sense in the context of Elixir (or Erlang) being dynamically typed. If Elixir (and Erlang) was statically typed then an error would make sense.

Dynamically typed languages lend themselves to REPL-Driven-Development, i.e. you can build and exercise code in the absence of other functionality (to be added later) as long as your current runtime execution path doesn’t run off into the “other non-existent” parts of the code. With a statically typed language this is impossible - you would at least have to “stub out” all the other parts of the code - even if you currently do not plan to execute them at runtime (during development).

Now granted unlike JavaScript, Elixir (and Erlang) still needs to successfully compile before anything can be run - but to use XML terminology - successful compilation simply means the code is “well formed” but it doesn’t mean the code is “valid”. The fact that Elixir (and Erlang) requires compilation should never be mistaken for it being “equivalent to” statically type checked

By only issuing a warning, you are free in development to write and run tests for parts of the behaviour that do not rely on that particular callback. This would be especially handy for behaviours with a relatively large number of callbacks. So the warning lets you get the first tests to run much more quickly - without necessarily having to sketch out the entire behaviour implementation first.

Now deploying code with these type of warnings (or ideally any warnings) into production would be questionable.

Well, contracts are worth nothing if they are not enforced. I actually find this compromise rather surprising.

I don’t know the rationale, however to turn warning into error yourself you can pass --warnings-as-errors to mix compile, mix test and many other tasks.