There are software bugs, which are functional and programmatic mistakes in the code. And there are software weeds.
A sloppy class interface with cumbersome, badly named, or coupled methods may be perfectly correct functionally. The author of the class may not care about improvements, e.g. because of the time pressure. The code reviewer may point out that the class could be cleaned up or generalized, but it often is perceived as splitting hair: after all the class is used only at one spot, and there is a deadline coming on the next week, and the developer's ego often is in the way.
Although used only at one place, the class has a unit test, meaning that it already is not really a single use. A few weeks later, another team member decided to use the class elsewhere, because it is doing exactly what he needs.
A few months later, the class is used in a two-three projects run by different teams. At that point, if a tiny change in it is required, no-one wants to touch it, since all the consequences have to be analyzed, a handful of stakeholders consulted, and tons of code fixed.
That's how a software weed comes to life and spreads: something looks too negligible to keep is clean. It is not a bug and requires a different approach: the only way to get rid of a software weed is to spot and stop it early, despite psychological it-is-too-small-to-care resistance.