1) reading a pile of code and trying to figure out how it works and being constrained by someone else's solutions is considerably less fun for most developers than writing something new and making decisions about how the system will be put together
2) It's much harder to point to what you did or talk up your accomplishments. Particularly to management.
Re 2. This is very true.
2: write reams of documentation for every function and module and service you decode, check them off on a checklist, and point out how you generated x pages of new docs and analyzed y% of a previously mysterious codebase. Then when you refactor, you get to point out how many thousands of lines of obsolete PL/SQL code you replaced with 10 lines of Ruby.
I would not touch with a ten foot pole the code churned out by AgileSprints(TM) held by computer-illiterate management to hit some arbitrary deadline.
The stigma is on shoddy code, which, alas, seems the norm in large swaths of our industry.
Most developers wouldn't. There's a stigma against maintenance. Most developers want to be Software Architects! (Said with the pigs in space voice).