1. Debug logs can contain private informations that should not be stored in the log system. For example email can be considered PII, which mean that your logs now require to be able to comply with GDPR (assuming you are operating in EU) and you need to provide and remove that informations on request, including historical data.
2. Overloading logging system. Debug logs are often defined to be very descriptive and can contain a lot of information, as well as fire quite often. This can overload logger and then cause backends/handlers to just drop them on the flor to prevent system from DoS.
3. Signal to noise ratio. Debug logs can be quite noisy and can hide important and relevant information in SQL queries and stuff like that.
4. Network transfer in case of centralised logging systems. Mostly the same points as in 2., but with different place where the slowdown/congestion can happen.

Until you will have breach, and your logs will be read not only by You.

Then you probably use wrong log level for that data.

Not really. BEAM can actually be a problem there as sending messages to processes is cheap and have negligible backpressure. Unbounded growth of the mailbox can cause VM to OOM and degrade performance of all processes. That is why Elixir, Erlang, and Lager implement some kind of overload protection mechanisms. Additionally that is the reason why Elixir do not encourage people to use “Erlang handlers” instead of “Elixir backends”, as there is no reliable way to have such mechanism in Erlang handlers yet.

Yes, that is why Erlang use notice as a default level, and Elixir currently uses some hacks to work around it for compatibility reasons.

Debug logs are meant for debugging. If you want to have them enabled by default in production, then you have used wrong level in the first place. So you are looking wrong way at the problem - make interesting logs for you use higher log level instead of lowering primary log level.