I've often noticed developers seeing a project for the first time and not long after proclaim it as "bad code" and that it needs to be refactored or rewritten (with zero thought as to whether it's good for the customers or the business.)
From experience, those announcing that a codebase is bad sounds more resume-driven than technical. It sounds like they want to make a mark more than making a functional difference. "Bad code" that happens to have a knowledgeable team around it is not that bad, it's just not understood by outsiders immediately. Also, given the rate of turnaround in teams and companies, making large and significant rewrites and changes would probably not tend to be seen through to their fullest conclusions, in that one sees the long term effect of a large rewrite.
I think if a codebase is actually bad and if codebase aesthetics are an important aspect to one's career, finding the next company with a potentially better codebase is probably a better thing to do than blanket and uninformed critiques about other people's work. :)
Graybeard here (been doing development for money for 40+ years). It's one thing to say a codebase is bad because of style, aesthetics or lack of comment; it's another to try to enumerate what that means. To me, a codebase is bad when it's hard to modify and hard to unit/integration test because of the architectural decisions that were made (which boil down to it not being properly layered and modular, overusing inheritance vs composition, using inscrutable variable names, etc).