The problem

One must be cautious using or leaving System.debug() statements around the code because of the following:

• It will have a direct impact affecting the performance of our applications. Refer to Simon Lawrence's answer on this thread when testing the load of a visualforce page with and without system debug statements.
• Uncontrolled debug statements will create unnecessary log lines that can directly affect the size limit of the logs. Review here in the Debug logs have the following limits section.
• If they exist in excess, they can even overwrite the traces we are trying to set. Debug logs automatically get reduced in size by removing older log lines if the size limit is reached.

One common approach I found in different orgs is to create one or many specific Debug log flags set in a Custom Setting boolean value which gets activated if needed. It can be a good practice for small and some medium size developments, but once the project keeps growing, a better functional approach is needed.

Logs switched on and off by class

1. Create a metadata type or custom settings for controlling the list of classes we want to have logs from.
2. Create a Debug handler class for adding parameters like the class from where the log gets invoked. (Evaluate if we can make it more granular, function level)
3. Dynamically change the log level of the debug statements from that class directly from the metadata type or custom setting.
4. Add expiration time for switch it off automatically.

Conclusion

This approach is just to have a better control when debugging with System debug statements. It can be customized as needed.
Keep in mind that when the complexity of the project keeps growing and the default Salesforce logging system is not enough to reproduce the error, or the cause of the error depends on data that is managed by a non-persistent feature, like Platform Events, its recommended to consider having a dedicated custom object to persist custom log data. Check this article: Without A (Debug) Trace: Easier Logging in Apex, where Mike Jutzin's explains this useful approach.

Useful external links:

• How to control the debug level in the developer console? 
• How System debug statements affects performance?
• Debug Log levels
• Without A (Debug) Trace: Easier Logging in Apex