In my area of business - back office IT for a financial institution - it is very common for a software component to carry a global configuration around, to log its progress, to
I think this is a misconception, only the IO monad is not pure. monads like Write/T/Reader/T/State/T/ST monads are purely functional still.
There seem to me more than one notion about the term pure / non-pure. Your definition "IO = unpure, everything else = pure" sounds similar to what Peyton-Jones talks about in "Taming effects" (http://ulf.wiger.net/weblog/2008/02/29/peyton-jones-taming-effects-the-next-big-challenge/). On the other hand, the Real World Haskell (in the final pages of the Monad Transformer chapter) contrasts pure functions to monadic function in general - arguing that you need different libraries for both worlds. BTW, one could argue that IO is pure as well, it's side effects being encapsulated in a State function with type RealWorld -> (a, RealWorld). After all, Haskell calls itself a purely functional language (IO included, I presume :-).)
My question is not so much about what can be done theoretically, but more about what has been proven useful from a Software Engineering point of view. Monad transformers allow for modularity of effects (and abstractions in general), but is that the direction programming should be heading to?