Different people create things that they think constitute "good" code, and to that person it makes perfect sense. But to another person that's an unmaintainable mess or unclear. Fortunately code reviews can help this situation. But sometimes a developer could have spent a lot of work re factoring (really re-designing) parts of a system, and by the time the code review comes, you can spend some time helping make it a little clear, but if the whole design is unclear often you are stuck with it and things go live.
The way much code ends up more readable is by introducing abstractions, but if those abstractions only make sense to one developer (or a group of developers who are all best buds) then they don't really help and can make things more complicated.
In reality some people say 500 line methods are unclear, and often they are. But if the object oriented alternative has really shoddy naming, and people were unreasonable so multiple class hierarchies are involved, each one throwing code in constructors, and multiple methods which often have side effects in multiple objects...that 500 line "bad code" starts looking pretty good to the alternatives. But to the developer who wrote the object oriented solution, his code is good and the 500 line method was a monstrosity.
Sometimes even the same developer changes his/her mind about code being good/bad. Six months ago, it was good, now it sucks....
And there also seems to be no universal agreement. At work they have coding standards, but they are constantly changing. Heck for a while design patterns were considered the stuff.....use them wherever you can. Then design patterns were too complicated....use them sparingly. The definition of good vs unmaintainable mess is constantly changing.
So due to this whole "good" vs "bad" being not universal and the definition of "good" changing over time...it is hard to justify taking the time to do something "right" when often you end up with the same unmaintainable mess. In fact over 4 jobs (about to start number 5) I have not met code that I think is a pleasure to work with or is GREAT. I definitely think some was better than other code, but even that wasn't great. And when I look back at code I did, often I am not thrilled and think I could do better. But the reality is that at the time of designing the system, there was no way to anticipate when things changed, and the deadlines were pretty arbitrary/tight. If someone says you have 1 day to get this web page done....I would start writing inline HTML/Database queries to crank something out probably in 1.5-2 days (and possibly try to convince someone to let me write it in Perl for a 1 day special).