When code executes on a client-side browser, it is difficult to collate and report errors on their machine. If you have code that is client-side, then how do we collect remote client information onto an internal system? How do we organise such information? And how do we yield significant results without being overwhelmed by false-positives?
The problem with fine-tuning your logging to debug level, is that you can suffer from information overload. It becomes harder to see the wood through the trees, that is, you have no idea what the true problems your clients are facing from a day-to-day basis when working with your application. If you reduce the amount of noise received from client browsers, then it will allow you to diagnose real errors swiftly.
These are the basic questions you should ask yourself when an initial diagnosis is performed. If an error is reported without a stack trace or environmental data, then it becomes harder to understand how to reproduce the error and fix it. There can also be specific metrics like what does the current memory heap look like? What are the current values of the variables in the current context in code?
All these questions matter when trying to understand how to fix bugs, and not fix the wrong problem.