console.log statements should generally not be in production-released code. They are meant to aid in debugging before the code gets to a production environment. In compiled languages, there's usually a compiler flag for debug/production modes, and in production compilation, all debug statements are removed. This is an ancient practice that allowed developers to see how their code behaves, yet remove the bloat and CPU time sinks for their customers.
In the case of Apex, conditional debug statements can harm code coverage and/or test/deployment times, can leak sensitive information, and are generally CPU time sinks for the millions of transactions that will follow where no debug logs are generated. Even worse, as a CMDT, someone could accidentally package it in an "on" state and slow down the entire system for everyone, with literally no benefit.
In fact, I've proposed a code review rule with basically every team I've worked on that
System.debug automatically fails the review. I even very nearly made a precommit rule forbidding the use of logging. It is both a CPU time sink and a potential security risk if not used correctly, so the safer alternative is to outright ban the use of debug statements.
Similarly, be wary of the use of
console.log statements. While the user can inspect the memory state at any time, literally handing the customer potential "secrets" on a silver platter is generally not ideal. In addition,
console.log statements take up both CPU time and memory. Excessive logging can harm browser performance, just as it can on other types of platforms.
Since there are better ways of debugging, such as literally using the debugging tool built in to the browser, there is no reason to log copious amounts of data to the console. You can use breakpoints, watchpoints, and other tools to efficiently examine what is happening in your code without any logging whatsoever. As far as client-side logging, it's not like there are actual "governor limits," but be aware that excessive logging can slow down a browser significantly.
So, summarized, it should be said that debug statements are for debugging code, not production code, and therefore you should never have any type of logging in your production code. If you need to debug a specific problem in production, you should add in the appropriate logging temporarily, install an upgrade package, and then revert the logging out when you're done. Alternatively, try to avoid debugging in production entirely. Create a Sandbox, add all manner of debugging in a Beta package, fully test it, then revert all of the debug logging when you make a Release package.
For First-Generation Managed Packages, this can be done by creating a Beta version with debugging code where you need it, which is then installed in to a Sandbox or Scratch Org for testing and replication. In Second-Generation Packaging, you can create an alternative "branch" by setting the appropriate ancestor, do whatever testing you need, then roll any fixes back in to the main branch. Afterwards, you can delete the side branch as it is no longer necessary.