Maybe I've worked with bad code for too long, but my opinion is, being the one person who understands some clusterfuck of poorly designed and hard to read code is job security and improving it can be satisfying. Reducing coupling, making a codebase more readable, rewriting code to make it more unit testable, or making a given piece of code run faster I find to be satisfying and educational. You learn from direct experience a myriad of ways in which not to do things and exactly why not to do them, and you can use this information going forward when you write your next feature.
It can also be incredibly frustrating. There's a human reason the code is a mess, and unless that situation changes, the code will rapidly revert to a mess no matter how clean you make it.
Not necessarily. At least in my experience, most people want to improve their coding skills and if you build a good relationship with your coworkers and have a track record of putting out good work, then you'll be in a position to offer up suggestions on how everyone can improve.
Or the management will come and say that they signed another contract for something that has to be done in 3 months (they said it's already basically ready, just a few last brushes to go) and now there is no time to do anything right. Everything becomes its worst possible version and every day you pray that you will never ever have to look at the code you've just written again. And then you look at the code others have just written and now you have to work with, and you wish you were never born (or dream about being a baker).
When the underlying problem is a lack of knowledge in the group, it can be easily fixed by the introduction of someone with the neccessary knowledge. In that case, you are solving the human problem. That's one of many possible reasons for why the code is a mess.
