I think you are right about your sentiment here, vesuvius. The software world is a world of fashion. Trends come and go, be it project management or ways of programming. Right now the trend is a very factory-like approach that appears to have been proven succesful in practice but it probably has its own set of costs and in time I could see a counter-trend arising.
In my oppinion SCRUM lends itself less to creative development because everything is focused on "getting the job done in time" and less about how the job is done - it's purely about project management in a way and less about overarching architechtural concerns. The short-term progress is measurable and easily defensible whereas the possible costs in terms of hacks and unsound architechture is something that does not show directly, instead it shows up in how long it takes to solve problems in the system over time. At least it requires some backbone to make sure short-term commercial concerns do not create short-term solutions.
It's clear that it should be a goal of every developer to be proud of his/her code. Sometimes short-term concerns just make that kind of code impossible.
To explain to the customer: it would really help out if we refactored this part of your system. But what's the business value of refactoring? Yes, we'll be able to develop in this part of the system faster in the future and you'll have less bugs...