In my experience it is almost always the case. I think this is a case where Dunning-Kruger* often applies, which is to say that you enter this new environment and think you know what's going on only because you're so completely ignorant of the details. Other times it's simply that decisions were made that made sense at the time and only look stupid with the benefit of hindsight. In either case, that bad code probably still exists in production for a very legitimate reason: the trouble it causes isn't worth the cost to fix it.

*I'm aware that DK doesn't really say what the common interpretation says it does

Another concept that complements this is the fundamental attribution error. It's called that for a reason. Instead of first assuming that everyone who came before was a terrible coder/worker/person, you have to look at the context and incentives at play.

I find the common cause of bad code is changing requirements. If someone is given the choice of a change that takes 1 hour or 1 week it's very hard to stick with clean code. Make a change and then undo it more than once, and it's easy to leave a few if (false) bits hanging around that don't break anything today.

Next biggest issue is a changing team. If you don't really understand some bit of code it's often safer to code around it than mess with it.

If the code works and produces money for the company, no excuse is needed.

Perhaps the founder had better things for his time than perfecting some code that was already good enough to get clients/VC money.

That attitude makes sense, initially.

But continuing to ignore code quality (and potential security issues) and blindly piling on complexity and feature creep and hoping for the best is just playing Russian roulette with your money.

If the company expects continuing maintenance and feature additions to that same code, then yes, a better excuse is needed.

Sure. But they can pay someone to fix their mess when that time comes.

It's a "nice problem to have" kind of thing.

There is no general answer. In any given case, you don't know.

Just you would like for people to assume you have the best intentions and reasonable practices, you should also provide some respect to the developers of the original code and not assume what you see in production is necessarily their best work or the way they would do things now.