By default the $wgDebugComments = true; is almost useless because the log is full or long stacktraces of suppressed warnings. I think those should not be on the default log by default. I haven't found an easy way to get rid of them apart from editing the code.
In resolving T75619: Debug: Log group 'error' for PHP errors should abide wfSuppressWarnings, @Krinkle chose to emit log events for suppressed errors to the error-json log channel. In my opinion, suppressed errors should be discarded entirely. I don't understand the need to have an event stream to track events that are being deliberately ignored by the code authors.
Given the choice I'd remove the error-json and exception-json log channels entirely. With the introduction of PSR-3 log handling and the ability to use Monolog as the implementation library the operator of a given MediaWiki installation has the opportunity to configure various output formats for any log channel. This flexibility allows recording structured events when desired without incurring the overhead of additional string processing for deployments that are not interested in capturing the events.
There were some changes related to the handling of the $dest argument to wfDebug and wfDebugLog that have also effected the $wgDebugComments = true; behavior. The use of false, 'log', or 'private' for this argument (all non-default values) will no longer exclude the log event from being processed by MWDebug::debugMsg when MediaWiki\Logger\LegacyLogger is in use. Fixing this regression would remove the error-json noise as well as the messages to the error-json and exception-json channels are marked for exclusion via 'private' => true in the log event's context.