Another example is the multipart parser:

-- | Read a multi-part message from a 'Handle'.
-- Fails on parse errors.
hGetMultipartBody :: String -- ^ Boundary
-> Handle
-> IO MultiPart
hGetMultipartBody b h =
do
s <- BS.hGetContents h
case parseMultipartBody b s of
Nothing -> fail "Error parsing multi-part message"
Just m -> return m

Yes, that's definitely on the scary side of things.

However, you don't have to go all the way to drinking the Iteratee Kool-Aid in order to write safer networking code that is still performant. Here are a few projects I'm actively working on in this area:

I'm adding epoll support to the threaded RTS. This is a necessity for server performance.
I've added support for sending and receiving lazy ByteStrings to Johan Tibbell's network-bytestring library. A quick benchmark with a toy HTTP server has shown this to be about 2x faster than writing ByteStrings to a Handle (i.e. 14,000 requests per second, vs 7,000).
I've got a continuation-based resumable parser combinator module for attoparsec in progress, which uses lazy ByteStrings for blazing performance. You can use this to write protocol parsers in a completely clean way, decoupled from the underlying network receive operations.

While much of this isn't quite ready for use yet, this just represents one person's work, and there are lots of people beavering away actively at corners of the problem space that interest them.

I actually think that we're very close to being in fantastic shape here. I'm working on a memcached client library that uses the above libraries, and it's faster than the absolute best C memcached client (libmemcached), while also far smaller and elegantly layered. As a community, we are developing many proofs that you can have beautiful code without sacrificing performance.