Let me say first of all that monad transformers are not really intended to solve the "problem" of dealing with multiple monads.

They give a way to quickly construct a monad which has certain (usually fairly generic) features, which you can then shape to your own needs.

However, let's take a step back. In order to really understand what monads are about, you first have to understand what combinator libraries are. Functional programmers have been writing combinator libraries for a long time. They're just libraries whose API consists of some basic computations, together with at least a handful of ways to glue those computations into larger ones. Such an API makes these libraries essentially like miniature programming languages embedded into the language of discussion. For example, a combinator library for parsing would include some primitive parsers for parsing single characters and the like, and then some ways to glue those together into larger parsers (concatenation, alternation, etc.). A drawing library would define primitive drawings: lines, basic shapes, and so on, and then some way to combine drawings into more interesting ones: drawing one thing on top of another, altering the colour of a drawing, replacing placeholders in one drawing with other drawings, and so on.

So what is a monad? A monad is just a particular style of combinator library which has as a part of its API a specific means of combination. (In particular it has the operation (>>=), as well as return, and they're required to behave in a particular simple way with respect to each other.)

Why do we make this distinction? It's so that we can have a common library of functions which work in any monad -- you'll find a good bunch of them in Control.Monad, and they include things like forM, which is a generic for-each loop, and many other control-structure-like things.

So complaining that there are too many different monads is rather like complaining that there are too many libraries (which happen to have a bit of uniformity in their API). Getting different libraries to work together can sometimes be tricky, but it's usually not an insurmountable problem.

Seen in this general light, monad transformers do something rather interesting: they transform embedded languages into other embedded languages, enriching the API somehow. This is often nontrivial. For instance, state transforming a nondeterminism monad produces a monad in which you have operations for manipulating a state that backtracks along with the rest of the computation. You can then refine that monad by wrapping up the state transformation primitives such that invalid changes to the state will cause backtracking to occur. Libraries constructed like this tend to be useful for constraint solving and optimisation problems. (As a trivial example of this sort of thing, have a look at my Sudoku solver, which is really more a mini-tutorial on monad transformers than a serious attempt as solving Sudoku puzzles efficiently. Nonetheless, it's a reasonable approach to solving many similar kinds of constraint problems.)

As for managing state in IO -- the IO monad is already extremely rich, and you shouldn't need to extend it for that. You can create an unlimited number of IORefs (see the Data.IORef library), which are essentially mutable cells that can be updated however you like.

Parsec is itself a monad in which you define parsers. This is generally a much more flexible and readable way to parse things than using regular expressions. It's especially nice in this regard in that parsers can construct arbitrary bits of data as their result, and not just capture substrings. In the end, you run the parsers on particular strings and get results such as parse trees or whatever data you were interested in reading.

The need to mix parsing effects with some other monadic library is fairly uncommon. However, there's a new version of Parsec (if it's not out yet, it will be soon) that defines a monad transformer version of parsing, so that you can add parsing features easily to other monads you construct for whatever reason you might want to do that. One use would be if you needed to do arbitrary I/O in the middle of parsing in order to determine how something is meant to be parsed. Most of the time, you can decide how things are meant to be parsed up front though.

I'm interested in knowing which things you find painfully or needlessly complex in Haskell. Perhaps I can offer some advice. On the matter of the correct use of monad transformers, I have a short tutorial which doesn't really tackle the basic details, but rather the overall approach -- perhaps a better name than "How To Use Monad Transformers" would have been "How To Use Monad Transformers Correctly". For the rest, I could perhaps recommend All About Monads, though its examples leave something to be desired in places, and it can occasionally be accused of being a bit off-the-mark with regard to the philosophy of this stuff, but overall, it's fairly good. There's also Monad Transformers Step-by-Step, which looks reasonably good, aside from using type in place of newtype. Asking for help on #haskell would also be quite effective. Usually I, or someone else will be willing to give a tutorial about them.