The KlassMaster docs actually summarize the reason why fairly well.
Since the class
com.mycompany.c will typically have been obfuscated to contain many overloaded methods with the names
b, diagnosing the problem and reproducing the bug will be very time consuming for your developers and very frustrating for your customers.
They provide a stacktrace below this summary. I'll focus on these four lines:
Clearly in these stacktrace elements the class is always the same
c, but what about the method? Lines 1, 2, and 4 give the method name of
a but the issue is that you cannot be sure if these all point to the same method due the name overloading (multiple methods with the same name but different return / parameter types).
This is where line-numbers come in. Since you are a developer with source-code access you can easily jump to the line number that the stacktrace provides. An attacker will not have the source-code but they can just as easily look at the class's bytecode to make a table that associates different line numbers with their methods (and more specifically, where in the method bytecode the issue occured). This would allow them to bypass the purpose of name overloading since they can lookup what method is associated with a line in any given stacktrace element.
If you were to remove line-numbers then an attacker cannot take any given stacktrace element and instantly know what method it links to. The attacker's best option in this case would be to start at a known position in the stacktrace and manually follow the bytecode to determine which of the overloaded methods is being shown in the stacktrace.
If decompilation is your highest priority concern rather than a situation like the above, then you should keep the debug information for your sake. Java decompilers can produce fairly accurate code even on obfuscated assemblies regardless of whether debug information is included or not.